Workspaces, domains, ownership and endorsement
- Why it matters
- Workspace structure and endorsement decide where people look for data and which numbers they trust. Without them, every team builds its own copy.
- Typical production failure
- Nineteen models, five customer tables and four names for revenue (Sprint 10), because nothing tells users which one is official.
- When to use it
- Domain workspaces with named owners, separate Dev/Test/Prod for content many people rely on, promotion for good team content, certification with written criteria for company-wide models.
- When not to
- Certifying content no one owns, or a review process so heavy that teams stop asking.
Assignments
A workspace and domain plan for Northwind
Using the Sprint 10 inventory, propose how workspaces should be organised: names, domains, who owns them, which ones get Dev/Test/Prod, and what happens to personal and test workspaces.
Requirements
- A naming convention.
- A domain per business area with an owner.
- Workspace roles: who is Admin, Member, Contributor, Viewer, and why consumers use apps instead of workspace roles.
- Which workspaces need deployment pipelines.
Expected result: Domain workspaces (Sales, Finance, Operations, Marketing, HR, Supply Chain) with named owners and a convention like "<Domain> – <Purpose> [Dev|Test]"; at most two or three Admins per workspace; consumers through apps or audiences; pipelines for workspaces holding certified models; personal and test workspaces kept out of production use.
Write the certification criteria
Elena asks for the criteria a semantic model must meet before it's certified, short enough that people read it, strict enough that "certified" means something.
Work out
- Ownership, documentation, testing, security, refresh, performance and change control.
- Who can certify and how certification is reviewed or removed.
What good looks like: One page: named business and technical owner; KPI dictionary and measure descriptions; data and model tests passing; RLS test matrix where relevant; refresh monitored with team alerts; meets the performance budget; changes through Git and a pipeline; reviewed yearly; certification removed when criteria lapse. Only a small, named group can certify.
Promoted or certified?
Classify five items: endorse as Promoted, Certified, or neither. Justify each.
Requirements
- The shared sales model with an owner, tests and a KPI dictionary.
- Marketing's campaign model, used by its own team, maintained but undocumented.
- A copy of the sales model someone made to add one measure.
- Finance's board pack model, owned by the CFO's team, reconciled to the ledger monthly.
- A one-off analysis for a single meeting.
Expected result: Certified: shared sales model, Finance board pack. Promoted: Marketing's model (useful, maintained, not company-wide). Neither: the copy (merge the measure into the shared model and retire it) and the one-off (personal workspace, then delete).
Interview questions
- Promoted vs certified?
- What are Fabric domains for?
- Why shouldn't report consumers be workspace Viewers on a development workspace?
- What makes governance actually work?
Assessment
Who can certify a semantic model?
- Any workspace member
- Only users authorised by the Fabric administrator for certification
- Only the model owner
- Anyone with Build permission
A team copies the certified sales model to add one measure. Best response:
- Certify the copy too
- Add the measure to the certified model (or a composite on top) and retire the copy
- Ignore it
- Delete both
In a trial tenant, promote one model, request certification for another, and find both in the OneLake catalog with the endorsement filter.
Settings → Endorsement and discovery on the item.