What it is
A Domain is a logical container that groups workspaces sharing common business context. Examples: "Finance", "Supply Chain", "Customer", "Product Analytics". A workspace belongs to one domain (with optional sub-domains for finer granularity). Domains have their own admins, branding, and policies.
Why domains matter
Three things become possible when domains are in place:
- Federated ownership. Each domain has named owners who govern their data products without going through central IT.
- Discovery scope. Users search within a domain instead of across all 200 workspaces in the tenant.
- Policy delegation. Sensitivity-label requirements, endorsement workflows, and capacity allocation can vary by domain.
Designing your domains
- Start from how the business is organized, not how IT is. Sales, Marketing, Finance — not "Data Platform" and "BI."
- 5–15 domains is usually right. Too few = no value; too many = federation overhead.
- Use sub-domains sparingly. They add overhead.
- Name domains in user-facing terms. "Customer Insights" beats "CINS-PROD".
Domain governance
- Each domain has at least one named admin (person, not group inbox).
- Each domain publishes a "data product" inventory in the OneLake Catalog.
- Endorsement (Certified / Promoted) is approved at the domain level.
- Cross-domain sharing flows through Shortcuts, not pipelines.
Best practices
- Establish domains before you have 50 workspaces. Retro-fitting hurts.
- Capacity per domain. Domain-scoped capacity makes chargeback easy and shields one domain from another's spikes.
- Document the operating model. Who owns what, who approves what, what the domain promises to consumers.