Skip to main content

An enterprise Power BI architecture has five layers. Workspaces are grouped into Fabric domains, follow a naming convention that shows owner, purpose and stage, and are split into data workspaces for shared semantic models and reporting workspaces for reports. A small number of shared semantic models, endorsed as Certified by reviewers that a Fabric administrator designates, serve many live-connected reports. Deployment pipelines with two to 10 stages move content from development to test to production, with deployment rules swapping data sources and parameters per stage. Workspaces are assigned to Fabric capacities by criticality and watched with the Capacity Metrics app. Governed workspaces add security groups, sensitivity labels, source control and auditing. EPC Group, a Houston-based Microsoft consulting firm, designs estates on this pattern.

Key Facts

  • Each workspace can be assigned to only one Fabric domain, and domains group workspaces into a single management boundary (Microsoft Learn, Power BI implementation planning: Workspaces at the tenant level, accessed 2026-10-20).
  • Managed self-service BI is about minimizing the number of semantic models by reusing shared semantic models for a single version of the truth (Microsoft Learn, Power BI usage scenarios: Managed self-service BI, accessed 2026-10-20).
  • Any user can request certification, but only users specified by a Fabric administrator can certify items (Microsoft Learn, Endorsement overview, accessed 2026-10-20).
  • A deployment pipeline can have anywhere from two to 10 stages, with three stages by default (Microsoft Learn, Introduction to deployment pipelines, accessed 2026-10-20).
  • Deployment rules cannot be created in the development stage and take effect only the next time content is deployed to that stage (Microsoft Learn, Create deployment rules, accessed 2026-10-20).

Last updated by Errin O'Connor, Founder & Chief AI Architect, EPC Group

The architecture in five layers

An enterprise Power BI estate is not a large collection of reports; it is a small number of governed data assets with a large number of reports built over them. Microsoft's implementation planning guidance frames the pattern as managed self-service BI: discipline at the core and flexibility at the edge, with a central team maintaining shared semantic models and business-unit creators building reports against them (Microsoft Learn, Power BI usage scenarios: Managed self-service BI, accessed 2026-10-20). EPC Group's Power BI consulting practice builds that pattern in five layers: a workspace topology organized by Fabric domain, owner and stage; a short list of certified shared semantic models; reports that live in separate workspaces from the models they use; deployment pipelines that move content through development, test and production; and capacity assigned by business criticality with monitoring attached. Each layer maps to a documented Microsoft control, and the sections below walk through them in the order EPC Group sets them up.

Workspace topology: domains, names and stages

Microsoft recommends making tenant-level workspace decisions as early as possible because they affect everything else. Who can create workspaces is set by the Create workspaces tenant setting, ideally scoped to a security group such as Fabric Workspace Creators. Workspace names should convey purpose, item types, stage and ownership, with a standard prefix such as FIN- and suffixes such as [Dev] and [Test] while the production workspace keeps a user-friendly name. Microsoft notes that renaming a workspace is usually safe because its GroupID does not change, but XMLA connections use the name and break (Microsoft Learn, Power BI implementation planning: Workspaces at the tenant level, accessed 2026-10-20).

Above individual workspaces sit domains. A domain groups related workspaces into one management boundary, can override certain tenant settings, and helps users filter the OneLake catalog; each workspace belongs to only one domain, and Microsoft suggests organizing by subject area, owning team, business unit or project. The same guidance lists the information a workspace request should capture, including stages needed, target audience, capacity, data residency and at least two administrators assigned as a group (same source). EPC Group runs that request as a short form with a service-level target of hours, not days, so that teams do not fall back to personal workspaces.

Shared semantic models and endorsement

The core design choice is to decouple models from reports. In the managed self-service scenario, semantic model creators publish a Power BI Desktop or Power BI project file that contains only a model to a workspace dedicated to shared semantic models; the model is endorsed and marked discoverable so it appears in the OneLake catalog; report creators request Build permission and use a live connection; and reports are published to separate reporting workspaces. Microsoft states that row-level security still applies to users in the Viewer role even when they hold Build permission, and recommends lineage view and impact analysis before changing a shared model, because every connected report is affected (Microsoft Learn, Power BI usage scenarios: Managed self-service BI, accessed 2026-10-20).

Endorsement makes the good models findable. Promoted means the creators believe an item is ready for sharing and reuse, and any user with write permission can promote it. Certified means an organization-authorized reviewer has confirmed it meets quality standards; anyone can request certification, but only users that a Fabric administrator specifies can grant it, and certification can be delegated to domain administrators so each domain has its own reviewers. A third badge, Master data, marks a data item as the authoritative source for a subject such as customer lists (Microsoft Learn, Endorsement overview, accessed 2026-10-20). EPC Group writes the certification checklist before the first model is certified: named owner, documented measures, tested RLS roles and a change process.

Deployment pipelines and deployment rules

Deployment pipelines give creators a managed route from development to production. A pipeline has between two and 10 stages, three by default, and deploying copies the selected items from one stage to the next, overwriting the paired items in the target. Pairing matters: items added to a workspace after it was assigned to a pipeline are not paired automatically, and unpaired items create duplicates rather than overwriting. Pipelines can also be driven through the Power BI and Fabric deployment pipelines REST APIs, and Microsoft points to Git integration for version control (Microsoft Learn, Introduction to deployment pipelines, accessed 2026-10-20).

Deployment rules keep each stage pointed at the right data. Semantic models support data source rules and parameter rules, paginated reports support data source rules, and notebooks support default lakehouse rules. Rules are created in the target stage, never in development; the creator must own the item; data source rules work only between sources of the same type; and a rule takes effect on the next deployment to that stage (Microsoft Learn, Create deployment rules, accessed 2026-10-20). EPC Group parameterizes the server and database names in every certified model so a parameter rule, not a manual edit, repoints production.

Capacity, monitoring and governance

Capacity is the shared compute every workspace on it draws from. Microsoft distinguishes interactive operations, such as DAX queries from reports, from background operations, such as semantic model refreshes, and recommends the Fabric Capacity Metrics app to find the items consuming the most compute. When throttling appears, the options are to optimize, scale up, or scale out by moving workspaces to another capacity, and Microsoft gives the example of a dedicated capacity for executive reporting; surge protection can limit background jobs but is not a substitute for those three steps (Microsoft Learn, Evaluate and optimize your Microsoft Fabric capacity, accessed 2026-10-20). EPC Group's Microsoft Fabric consulting team typically separates certified production content from development and self-service workloads, sets capacity notifications, and reviews the metrics app alongside the activity log.

Governance ties the layers together. Microsoft suggests starting with two workspace governance levels, governed and ungoverned, and lists the requirements a governed workspace usually carries: assigned ownership and a support path, a defined domain and naming convention, certified content, distribution through a Power BI app, security groups rather than individual accounts in workspace roles, sensitivity labels, separate development, test and production workspaces with source control and deployment pipelines, a managed and monitored capacity, a standard-mode gateway, and active auditing and monitoring (Microsoft Learn, Power BI implementation planning: Workspaces at the tenant level, accessed 2026-10-20). EPC Group records the governance level in each workspace description and audits governed workspaces against that list every quarter.

Documented work

ANON-CASES: EPC Group engagement data for enterprise Power BI architecture covers large construction-industry organizations consolidating report-per-model estates onto certified shared semantic models, domain-grouped workspaces and deployment pipelines, delivered by the firm's Power BI consulting practice. Client names are not published here. Engagements are described by industry and organization size only, and no outcome figures are quoted that cannot be traced to a signed deliverable. EPC Group is a Microsoft Solutions Partner with all six Solutions Partner Designations as of October 2026.

Primary sources

Frequently Asked Questions

How should workspaces be organized: by domain, by audience or by lifecycle?

All three, in layers. Microsoft describes Fabric domains as a way to group workspaces by subject area, owning team, business unit or project, with each workspace assigned to only one domain; naming conventions that carry purpose, ownership and stage, such as FIN-Quarterly Financials [Dev]; and separate development, test and production workspaces for lifecycle management (Microsoft Learn, Power BI implementation planning: Workspaces at the tenant level, accessed 2026-10-20). Microsoft also recommends publishing shared semantic models and reports to different workspaces (Microsoft Learn, Power BI usage scenarios: Managed self-service BI, accessed 2026-10-20). EPC Group applies domain first, then data versus reporting, then stage.

What is a shared semantic model, and why certify it?

A shared semantic model is published once, often by a central BI team, to a workspace dedicated to semantic models, and many reports use a live connection to it, which Microsoft describes as the way to achieve a single version of the truth (Microsoft Learn, Power BI usage scenarios: Managed self-service BI, accessed 2026-10-20). Certification means an organization-authorized reviewer has confirmed the item meets quality standards; any user can request it, but only users specified by a Fabric administrator can certify, while anyone with write permission can promote (Microsoft Learn, Endorsement overview, accessed 2026-10-20). EPC Group certifies only models with documented owners and tested measures.

How do deployment pipelines move content from development to test to production?

A deployment pipeline has between two and 10 stages, three by default, with a workspace assigned to each stage. Deploying copies selected items from the source stage and overwrites the paired items in the target stage; unpaired items create duplicates instead (Microsoft Learn, Introduction to deployment pipelines, accessed 2026-10-20). Deployment rules then swap stage-specific values: data source rules and parameter rules for semantic models, and data source rules for paginated reports. Rules cannot be created in the development stage, require item ownership, and take effect on the next deployment (Microsoft Learn, Create deployment rules, accessed 2026-10-20). EPC Group pairs pipelines with Git integration.

How is Premium or Fabric capacity allocated across workspaces?

Workspaces are assigned to capacities, and Microsoft describes three responses when a capacity shows throttling: optimize the items, scale up to a larger SKU, or scale out by moving workspaces to another capacity. Microsoft suggests separate capacities to isolate high-priority content, such as executive reporting, and self-service or development content, and recommends the Fabric Capacity Metrics app to see which items consume compute (Microsoft Learn, Evaluate and optimize your Microsoft Fabric capacity, accessed 2026-10-20). Microsoft lists assignment to an appropriate, monitored capacity as a governed-workspace requirement (Microsoft Learn, Power BI implementation planning: Workspaces at the tenant level, accessed 2026-10-20). EPC Group allocates by workload criticality.

How is the estate monitored and governed?

Microsoft lists typical requirements for a governed workspace: assigned ownership and support, a naming convention and domain, certified content, security groups for workspace roles, sensitivity labels, separate development, test and production workspaces with source control and deployment pipelines, a standard-mode gateway, and active auditing (Microsoft Learn, Power BI implementation planning: Workspaces at the tenant level, accessed 2026-10-20). For oversight, the activity log records user activity, and a high report-to-semantic model ratio indicates good reuse (Microsoft Learn, Power BI usage scenarios: Managed self-service BI, accessed 2026-10-20). EPC Group reviews those signals with the Center of Excellence each month.

Talk to a senior architect

If your tenant has more semantic models than report authors, or production changes are made by hand, a 30-minute discovery call with a senior EPC Group architect maps your current workspaces, models and capacities against this five-layer pattern. See the Power BI consulting service hub for engagement structures.

Email contact@epcgroup.net or call 888-381-9725.

a Microsoft Gold Partner (2000 until Microsoft retired the program in 2022) — today holding all six Microsoft Solutions Partner Designations.

Documented engagements

Each record publishes a redacted primary-source document — a client purchase order, executed agreement or payment record — with a SHA-256 hash you can recompute, and states what the document does not establish.

All documented client engagements

Related reading

AI assistant — not a human