> ## Documentation Index
> Fetch the complete documentation index at: https://honeydew.ai/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# How do I give different teams their own governed view of the data?
> Build reusable base domains that compose into team-specific, access-controlled views using domain hierarchy
## When would you use this?
* Different teams need different slices of the same model,
each with its own entity scope, filters, or field-level
access.
* You want governance rules (filters, PII restrictions)
defined once and inherited automatically, so child domains
stay in sync when the parent changes.
* You need to compose multiple concerns - for example, a
product filter combined with PII restrictions - without
duplicating configuration.
## What this recipe builds
A five-domain hierarchy where a base domain defines shared
governance, a team domain narrows entity scope, an executive
domain strips PII fields, a filter domain narrows to healthy
menu items, and a composed domain combines the filter with
PII removal via multiple inheritance.
```mermaid theme={null}
graph TD
A[tasty_bytes_core] --> B[fleet_operations]
A --> C[executive]
A --> D[healthy_items]
C --> E[healthy_items_executive]
D --> E
```
This recipe uses [domain hierarchy](/domains#domain-hierarchy).
See the documentation for the full technical reference.
## Steps
The foundation domain includes all entities and a baseline
governance filter that excludes zero-dollar orders from every
analysis. Every other domain extends this one.
```yaml theme={null}
type: domain
name: tasty_bytes_core
display_name: Tasty Bytes Core
description: |-
Foundation domain. All entities are in scope. A baseline
filter excludes zero-dollar orders.
entities:
- name: order_detail
- name: order_header
- name: menu
- name: date
- name: truck
- name: shifts
- name: customer_loyalty
filters:
- name: exclude_zero_dollar_orders
sql: order_header.order_amount > 0
display_name: Exclude Zero-Dollar Orders
description: Remove zero-dollar orders from all analyses.
```
The operations team manages trucks and shifts but does not
need menu items or customer demographics. This domain
extends the base and removes `menu` and
`customer_loyalty` using `merge: remove`.
The inherited filter (`exclude_zero_dollar_orders`) applies
automatically - no need to redefine it.
```yaml theme={null}
type: domain
name: fleet_operations
display_name: Fleet Operations
description: |-
Operations team view. Truck and shift data for
fleet scheduling and logistics.
extends:
- tasty_bytes_core
entities:
- name: menu
merge: remove
- name: customer_loyalty
merge: remove
```
**Result:** `order_detail`, `order_header`, `date`, `truck`,
`shifts` - with the zero-dollar filter inherited.
Executives need aggregate analytics but must not see personally
identifiable information. This domain extends the base and uses
field selectors to strip PII from `customer_loyalty` - names,
email, phone, postal code, and birthday.
Fields like `customer_id`, `city`, `country`, `age_group`, and
`favourite_brand` remain available for aggregate analysis.
```yaml theme={null}
type: domain
name: executive
display_name: Executive (PII-free)
description: |-
Executive view with PII stripped from customer data.
Preserves aggregate analytics fields.
extends:
- tasty_bytes_core
entities:
- name: customer_loyalty
fields: ["-first_name", "-last_name", "-e_mail",
"-phone_number", "-postal_code", "-birthday_date"]
```
All fields are inherited by default, so the child only needs
to list exclusions. Each `-field_name` selector removes one
PII field from the inherited set.
A domain that narrows the data to healthy menu items
only. It extends the base and adds a filter - all
entities remain available.
```yaml theme={null}
type: domain
name: healthy_items
display_name: Healthy Items
description: |-
Healthy-items view. Adds a filter for menu items
flagged as healthy.
extends:
- tasty_bytes_core
filters:
- name: healthy_only
sql: menu.is_healthy_flag = true
display_name: Healthy Only
description: Restrict to healthy menu items.
```
**Result:** all seven entities, the inherited zero-dollar
filter, plus the new healthy-only filter.
The healthy items executive domain combines two
concerns: the healthy filter and the executive's PII
restrictions. It extends both parents with no additional
configuration.
```yaml theme={null}
type: domain
name: healthy_items_executive
display_name: Healthy Items - Executive
description: |-
Composed view: healthy items filter with
executive PII protections.
extends:
- healthy_items
- executive
```
**Result:**
* Filter from `healthy_items` - healthy items only
* Fields from `executive` - no PII on `customer_loyalty`
* Filter from `tasty_bytes_core` - exclude zero-dollar orders
* Zero duplication - everything is inherited
## Key design notes
* **Filters inherit and can be replaced** - a child inherits
all parent filters. A filter with the same name replaces
the parent's version.
* **Field selectors extend the parent** - child field operations
apply on top of the inherited field list. Use `-field_name`
to remove fields, or `-*` then explicit names to restrict
to a specific subset.
* **`merge: remove` narrows scope** - use it to drop any
inherited item - entities, filters, or parameters -
without touching the parent.
* **Multiple inheritance composes** - parents are evaluated
left-to-right. If both parents define the same item, the
rightmost parent wins. The child overrides all parents.
## Related reading
* [Domains](/domains) - full reference on domain configuration,
filters, and field selectors
* [Domain hierarchy](/domains#domain-hierarchy) - inheritance
rules, `merge: remove`, and multiple inheritance
* [Row-level security](/security/row-level-security) - combining
domain hierarchy with warehouse-level access control