Power BI enterprise deployment: the decisions that make it scale

A Power BI enterprise deployment rarely fails on its visuals. It fails on a handful of decisions that are made early and are expensive to undo: who is licensed for what, how workspaces keep the people who build content apart from the people who read it, how semantic models are built for volume, where security is actually enforced, how content reaches production, and who hears when a refresh fails.

This guide takes those decisions in order and checks each one against Microsoft’s current documentation, because a good deal of what was written about scaling Power BI even two years ago no longer holds. The biggest change frames everything below: Microsoft is retiring Power BI Premium per-capacity SKUs and no longer sells new ones, so new capacity for your own Power BI content now means a Microsoft Fabric F SKU (the Embedded A and EM SKUs are outside the retirement). If you are still on a P SKU, the move itself is covered in Power BI Premium to Fabric, and this article does not repeat it.

Licensing: decide on who reads, not on headcount

The licence model is the first decision, and total headcount is the wrong number to start from. What decides it is how many people create content and how many only read it, because Microsoft licenses the two differently.

Microsoft’s Power BI pricing page lists Power BI Pro at $14.00 per user per month and Premium Per User (PPU) at $24.00, both paid yearly, and notes that Pro is “Included in Microsoft 365 E5 and Office 365 E5”. Actual prices vary by country and region.

The rules that decide who needs which licence are on Microsoft’s Fabric licensing page:

• Creators need a paid licence on every capacity. “To create Power BI items in workspaces that aren’t My workspace, you need a Pro license.” PPU also covers it; no capacity replaces it.
• F64 is the line for readers. “On F64 or larger, users with only a Free license and a viewer role can view Power BI content.” Below it, “each user viewing Power BI content must have Pro, PPU, or an individual trial.”
• PPU is a per-user feature set, not a capacity. “Premium Per User (PPU) doesn’t provision a Fabric capacity”, so it does not enable Fabric items beyond Power BI. What it adds is 48 refreshes a day, semantic models larger than 1 GB and the XMLA endpoint. Microsoft’s own guidance is that “PPU is more cost effective when Power BI Premium features are needed for fewer than 250 users.”
• PPU content needs PPU readers. “To access a Power BI Premium Per-User (PPU) workspace you need a PPU license or a Power BI individual trial.” A Pro licence is not enough to read it, so choosing PPU means licensing every reader of that content at the PPU price.
• F SKUs are an Azure purchase. Fabric capacity is bought in Azure, with optional reservations, and “Pricing is regional, and Azure bills per second with a one-minute minimum.”

What does the F64 route cost? Microsoft’s Azure retail price list gives Fabric capacity in East US a pay-as-you-go rate of $0.18 per capacity unit (CU) hour, and an F64 has 64 CUs. The rest is our arithmetic, not a Microsoft figure. 64 x $0.18 is $11.52 an hour, or about $8,410 a month over 730 hours, which is what roughly 600 Pro licences cost at list price.

Creators need Pro on either route, so their licences cancel out and the comparison is the capacity against Pro for readers only: at East US list prices, F64 costs less than Pro for everyone once more than about 600 readers would otherwise need a licence. Two things move that line. Readers with Microsoft 365 E5 or Office 365 E5 already have Pro, so they drop out of the count, and an F64 also runs Fabric workloads that Pro and PPU cannot. Check your own region in the Azure pricing calculator; reservations, covered in Fabric capacity planning, change the figure again.

Workspaces, apps and audiences: keep builders and readers apart

In a Power BI enterprise deployment, the workspace role someone holds decides two things: what they can change, and, as the security section below shows, whether row-level security filters what they see. Microsoft’s workspace roles reference sets out the split:

• Admins, Members and Contributors can all “Create, edit, and delete content in the workspace”.
• Only Admins and Members publish an app, unpublish it and change its permissions. “Contributors can update the app associated with the workspace if the workspace Admin delegates this permission to them. However, they can’t publish a new app”.
• Viewers view, and they are the only role that row-level security restricts.
• Groups can hold any role. “Workspaces allow you to assign roles to individuals, and also to user groups such as security groups, Microsoft 365 groups, and distribution lists.”

Microsoft’s adoption roadmap shapes the structure in two ways. On ownership, it names three strategies, “business-led self-service, managed self-service, and enterprise”, and for managed self-service it advises: “Consider implementing separate workspaces for storing data and reports.” That split is what lets one team own a shared semantic model while report authors build on it from workspaces of their own. It is worth getting right: in our experience, every data problem we are called in to fix eventually reduces to nobody being able to say who decides what a field means. On administration: “Specify between two and four workspace administrators and conduct an audit of workspace admins regularly (perhaps twice a year).”

Apps are the other way to give readers access. Microsoft’s app documentation sets the limits: “You can create one app per workspace”, that app can have up to 25 audiences, and “A total of 10,000 users and user groups combined can have access to an app.” Each audience takes up to 1,000 users or groups, and every workspace user is counted again in each audience. Microsoft recommends adding “one or more user groups that contain all the users who should have access” rather than named people. App readers follow the same F64 licence line as workspace Viewers, and those without Pro or PPU cannot copy reports.

Two details matter for the design. Audiences are not a security boundary: with “Allow access to hidden content” switched on, “If users have a direct link to any of the content in your app, they can access the hidden content”. Anything a group must not see belongs behind row-level security, not merely outside its audience. And Microsoft now has a second kind of app: “Workspace apps can coexist with org apps, which are Fabric items and a newer evolution of workspace apps.” Microsoft’s org apps guide describes them as generally available, allows several per workspace, and notes that their included items “aren’t versioned copies”, whereas a workspace app’s readers see nothing new until the app is updated. Existing workspace apps are not migrated automatically, so a new deployment has to choose between a publish step it controls and several apps per workspace.

Which semantic models count as the trusted source is an endorsement decision (promoted, certified or master data), covered in our article on Fabric domains and endorsement. Our position on the route to that status is that all global requests for enterprise reporting should go through the global IT team. Departmental self-service analytics can be shared inside a department, with caution, but must pass IT certification before it counts as a global solution.

Semantic models built for volume

Star schema first

Microsoft’s star schema guidance describes star schema design as highly relevant to building Power BI models for performance and usability: fact tables for the events you measure, dimension tables for the things you filter and group by, and relationships between them. Dimension tables do the filtering and grouping; fact tables are what gets summarised. DAX measures are calculated at query time, and their results are never stored in the model.

Size and memory

“The default size limit is 1 GB.” The large semantic model storage format, available on F, P and A SKUs and on PPU, is “required for semantic models to grow beyond 10 GB”. One consequence belongs in region planning: “Once a large semantic model is created in a workspace, it must stay in that region.”

Memory is the real ceiling. An F64 allows up to 25 GB of memory per semantic model, but Microsoft’s capacity limits carry a caution: “The maximum semantic model size permitted on a capacity might be smaller than the numbers in this column.” Refreshes and queries need headroom, and a refresh can more than double the memory a model uses.

Incremental refresh

Incremental refresh is not a Premium feature. “Incremental refresh is supported for Power BI Premium, Premium per user, Power BI Pro, and Power BI Embedded models”, according to Microsoft’s overview. The exception is the real-time DirectQuery partition that makes a hybrid table, which Pro does not support. Refresh time limits are two hours on Pro and five hours on Premium capacity, with refreshes through the XMLA endpoint the exception.

Two configuration details from Microsoft’s setup guidance decide whether the numbers are right:

• The date filter must not overlap. “Verify queries have an equal to (=) on either RangeStart or RangeEnd, but not both.” A filter that is inclusive at both ends can duplicate rows. The safe form is inclusive at the start and exclusive at the end:

“ Table.SelectRows(Source, each [OrderDate] >= RangeStart and [OrderDate] < RangeEnd) ``

• Change detection needs its own column. If you turn on detect data changes, "This column should not be the same column used to partition the data with the RangeStart and RangeEnd parameters."

One more constraint matters for deployment: "After publishing to the Power BI service, you can't publish the same model again from Power BI Desktop." Republishing removes the partitions and data already loaded. Microsoft documents two other routes for later changes: on Premium capacity, metadata changes made with tools such as the open-source ALM Toolkit or with TMSL, and deployment pipelines, covered below.

Direct Lake, where it fits

Microsoft's Direct Lake overview lists its licensing as "Fabric capacity subscription (SKUs) only" and positions it for lake-centric, IT-driven projects: "Direct Lake is an ideal choice for the gold analytics layer in the medallion lakehouse architecture." Import still suits self-service analysts. Three points matter before choosing it:

• Fallback depends on the flavour. Direct Lake on SQL can fall back to DirectQuery, for example when it meets SQL views or SQL granular security. "Direct Lake on OneLake doesn't fall back to DirectQuery mode via the SQL analytics endpoint of the data source."
• Guardrails depend on the SKU. On F64, a table can hold up to 1,500 million rows. Exceed a guardrail and the two flavours part again: on OneLake, refresh fails and the model cannot be queried until the Delta tables are brought back within limits; on SQL, the model falls back to DirectQuery if fallback is enabled, with slower queries.
• Some modelling tools are unavailable. User-defined aggregations and hybrid tables are not supported in Direct Lake.

Row-level and object-level security, and the roles that bypass both

The most important fact about row-level security in Power BI is who it does not apply to. "RLS only restricts data access for users with Viewer permissions. It doesn't apply to workspace Admin, Member, or Contributor roles." That is from Microsoft's RLS documentation, which adds that Build permission does not lift it: "Even if Viewers are given Build permissions to the semantic model, RLS still applies."

Microsoft's workspace roles page states the practical rule: "Use the Viewer role to enforce row-level security (RLS) for users who browse content in a workspace." Anyone whose data must be filtered reads through the Viewer role or an app, never from a Contributor or Member seat. It also means an RLS check run by someone signed in as a workspace Member proves nothing, because Members see everything.

The mechanics that matter at scale:

• Roles live in the model, members in the service. "You can't assign users to a role within Power BI Desktop. You assign them in the Power BI service."
• Role members can be groups, but not every kind. Microsoft Entra security groups, distribution groups and mail-enabled groups work. "Microsoft 365 groups aren't supported and can't be added to any RLS roles." Workspace roles do accept Microsoft 365 groups, so a group that works for workspace access may not work for RLS.
• Roles are additive. A user in two roles sees what either role allows.
• Bi-directional filters cost speed. "Enabling bi-directional security filtering can negatively impact query performance".
• Service principals sit outside RLS. "Service principals can't be added to an RLS role", and RLS is not applied where a service principal is the effective identity.
• Test as role is not a user test. "The Test as role feature in the Power BI service uses your own identity when evaluating dynamic RLS expressions." It cannot show what a specific person sees under dynamic RLS, B2B guests included, so validate with real accounts before go-live.

For an automated Power BI enterprise deployment with RLS, two facts carry the weight. Membership is assigned in the service, not in the file you deploy, and a deployment pipeline does not carry it forward: Microsoft's deployment process documentation lists "Role assignment" among the semantic model properties that are not copied. And RLS is not applied where a service principal is the effective identity, so an automation identity cannot show what users see. Assign role members in each stage, ideally as groups, and check them as part of every release.

Object-level security, which hides tables or columns rather than rows, follows the same rule: "OLS only applies to Viewers in a workspace." Per Microsoft's OLS documentation, "You can create OLS definitions using Tabular Model Definition Language (TMDL) view or external tools such as Tabular Editor."

Deployment pipelines and Git integration: promotion and history

Power BI deployment pipelines move content between stages, by default development, test and production, though Microsoft's pipelines overview allows more: "There can be anywhere from two to 10 stages." The decisions that shape them:

• The stage count is fixed at creation. Microsoft's getting started guide is explicit that the number of stages "can't be changed after the pipeline is created", so decide on a pre-production stage before building the first pipeline.
• Every stage needs a Premium workspace. "In a deployment pipeline, one Premium workspace is assigned to each stage", so a Pro workspace on shared capacity cannot be a stage. PPU works, with a limit set out in the lifecycle management FAQ: "PPU, EM, and A SKUs only work with Power BI items."
• Deployment rules belong to the model's owner. Rules let each stage use its own data source or parameter values, and "To configure deployment rules in deployment pipelines, you must be the owner of the semantic model."
• Pairing decides whether a deployment overwrites. "If items aren't paired, even if they appear to be the same (have the same name, type, and folder), they don't overwrite on a deployment." An unpaired item arrives as a duplicate, and items added after a workspace is assigned to a pipeline are not paired automatically.
• Some settings stay behind in every stage. Per the deployment process documentation, data, permissions and app content are not copied, and for semantic models neither are role assignment, the refresh schedule, data source credentials or endorsement. Production's RLS membership, credentials and refresh schedule are set in production.
• Incremental refresh survives promotion. Microsoft says pipelines "make updates to a semantic model with incremental refresh while retaining both data and partitions". Renaming a table that uses incremental refresh, or a non-calculated column in one, makes the deployment fail.
• Older semantic models are excluded. "Beginning February 12, 2026, Fabric deployment pipelines retire support for semantic models that aren't upgraded to Enhanced Metadata." Power BI items in pipelines are still marked as preview on Microsoft's list of supported items.
• Automation goes through the REST APIs. Microsoft offers both Power BI and Fabric deployment pipeline APIs. The Power BI call is POST https://api.powerbi.com/v1.0/myorg/pipelines/{pipelineId}/deployAll, with a "Maximum 300 deployed items per request", and the caller must be at least a Contributor on both the source and target workspaces, according to the Deploy All reference.

Git integration is the other half of the release path. Fabric's native Git integration connects a workspace to Azure DevOps, GitHub or GitHub Enterprise, cloud versions only, and lists Power BI reports and semantic models as preview, with exclusions. The deployment decision is who may connect it: only a workspace Admin can, per Microsoft's Fabric workspace roles. How Git and pipelines divide the work, which items sync and what that leaves uncovered are set out in our Git integration article.

Sensitivity labels and DLP inside Power BI

Labelling policy is a tenant-wide Microsoft Purview decision, and its rollout is covered in our sensitivity labels article. What is specific to Power BI is narrower, per Microsoft's information protection documentation:

• Applying labels needs two licences. "To be able to apply labels to Power BI items, a user must have a Power BI Pro or Power BI Premium Per-User (PPU) license", plus a Purview Information Protection licence.
• Protection travels on supported export paths only. Those are exports to Excel, PDF and PowerPoint, Excel workbooks connected live to the semantic model, and .pbix downloads. Exports such as .csv fall outside: "Access control in all other scenarios is unsupported."
• Labels flow downstream. "Downstream inheritance is on by default", so a label set on a semantic model carries to the content built on it.
• Mandatory labelling is fully supported for Power BI items.
• Labels do not always follow a deployment. Microsoft's deployment process documentation copies a label only when a new item is deployed, or an existing one is deployed to an empty stage, or when the source carries a protected label and the target does not, in which case it asks for consent to override. Otherwise the target stage keeps the label it had.

Data loss prevention for Power BI is narrower still. Microsoft's DLP for Power BI guidance lists three actions: a policy tip, an alert, and restricting access, the last in preview. "Only workspaces hosted in Fabric or Premium capacities are supported", and DirectQuery and live-connection semantic models are not covered, including models that mix import and DirectQuery. Designing the policies themselves is the subject of Purview DLP policy design.

Tenant settings and admin governance

Tenant settings are the main lever of Power BI governance at tenant level, and Microsoft's tenant settings overview is explicit about their limits: "Tenant settings that control the availability of features in the Power BI user interface can help to establish governance policies, but they're not a security measure." Hiding a feature is not a substitute for permissions, RLS or labels.

Settings can be scoped to, or exclude, specific security groups, so a feature can be opened to one group before the whole organisation. A change can take up to 15 minutes to reach everyone.

One setting needs a deliberate decision on Fabric capacity: "Users can create Fabric items", which opens items beyond Power BI. Microsoft's documentation on that switch notes that "Capacity admins can override this setting, depending on their needs", so the answer can differ by capacity. Treat it as a capacity decision as well as a governance one: in our experience, when end users are allowed to create their own artefacts, they consume capacity that goes unmonitored until everything is choked.

One decision belongs before go-live rather than after it: who runs the export of the activity log, which Microsoft's activity log guidance limits to 28 days of history, retrieved one day per request through an admin API. For scheduled, unattended exports Microsoft recommends setting up a service principal. Keeping that export running afterwards is covered in Fabric managed services.

Refresh failure alerting: decide who hears before go-live

Refresh alerting looks like an operations matter, but its defaults are fixed by deployment decisions: who owns each semantic model, and how its refreshes are triggered. Microsoft's refresh documentation sets the defaults:

• The owner hears, and only the owner. "By default, Power BI sends refresh failure notifications to the semantic model owner through email", and "each semantic model can only have one owner". Anyone else has to be added as a contact in the model's refresh settings, and they must be in your tenant: "Sending refresh notifications to external users is not supported."
• Only scheduled refreshes email. "On-demand refreshes and refreshes triggered programmatically such as through Power Automate don't trigger email notifications." A refresh started by an orchestration tool or the API fails without an email unless that tool raises its own alert.

Microsoft's scheduled refresh documentation adds three behaviours:

• Four failures switch the schedule off. "Power BI deactivates your refresh schedule after four consecutive failures", or when it detects an error that needs a configuration change, such as invalid or expired credentials, and "It is not possible to change the consecutive failures threshold." The owner is emailed when it happens, and the schedule stays off until someone fixes the cause and switches it back on.
• Unused models stop refreshing. "After two months of inactivity, scheduled refresh on your semantic model is paused."
• Frequency depends on the licence. "Power BI Pro: Up to 8 scheduled refreshes per day", against 48 on PPU, Premium and Fabric capacity, and a scheduled start can slip by up to an hour.

Put together: if a model's owner has moved on and nobody else was added as a contact, the failure emails and the email saying the schedule has been switched off both go to someone who will not act, and the model stops refreshing until somebody notices. In our experience, refresh failures after go-live are found by the people reading the reports, because BI teams set alerts on ETL failures but not on semantic model refreshes. The two decisions to make before go-live are therefore who receives the failure email for each production model, and what raises an alert for refreshes that run outside a schedule. Running that after go-live is the subject of Fabric managed services.

Capacity sizing: one decision here, the mechanics elsewhere

For a Power BI rollout, the capacity decision is which of three routes to take, shared capacity on Pro, PPU, or an F SKU, and, because every deployment pipeline stage needs a Premium workspace, whether development and test share production's capacity, get their own, or, for Power BI items only, run on PPU. Microsoft's migration guidance says how to size one: "baseline CU consumption by using the Microsoft Fabric Capacity Metrics app, and estimate future consumption with the Fabric SKU Estimator". That replaces sizing from user counts.

Two older assumptions no longer hold. "P SKU Autoscale doesn't exist on F SKUs", so peaks are handled differently on Fabric. And the monitoring tool is now the Microsoft Fabric Capacity Metrics app. How smoothing, throttling, scaling and reservations work is set out in Fabric capacity planning, and this article leaves them there.

Where to start: Power BI enterprise deployment services, in order

1. Count creators and readers separately. Price Pro for everyone against an F SKU plus Pro for creators, at your region's list price, and take E5 holders out of the count.
2. Choose the ownership model and the workspace split. Separate data from reports, assign roles to groups, and name two to four admins per workspace.
3. Build the shared semantic models for volume. Star schema, incremental refresh with a non-overlapping filter, large format where a model will pass 10 GB, and Direct Lake considered where the data already sits in a Fabric lakehouse or warehouse.
4. Put everyone who must be filtered behind the Viewer role or an app, and test RLS with real accounts as well as with Test as role.
5. Stand up the release path and the alerts. A deployment pipeline with rules, RLS members and credentials set in every stage, Git for history, and a named refresh failure contact on every production model, all before go-live.
6. Keep a written decision log. Record the region, domain model, workspace structure and capacity size, and the reason for each. In our experience it is the artefact that survives longest and is most often missing.

Veratas offers this as part of a Microsoft Fabric implementation. For a smaller, fixed-scope Power BI build, see our Power BI implementation service. If you are planning a Power BI rollout, or untangling one, talk to our team.

Frequently asked questions

Which licence do Power BI report readers need? It depends on where the content lives. In a Pro workspace, readers need Pro, PPU or an individual trial; in a PPU workspace, PPU or an individual trial; on an F SKU below F64, Pro, PPU or an individual trial. On F64 or larger, a Fabric Free licence with the Viewer role or app access is enough. Creators need Pro or PPU everywhere.

How much does Power BI Pro cost now? Microsoft's list price is $14.00 per user per month, paid yearly, and Premium Per User is $24.00. Pro is included in Microsoft 365 E5 and Office 365 E5. Actual prices vary by country and region.

Does row-level security apply to workspace members? No. Row-level and object-level security apply only to Viewers. Admins, Members and Contributors see all the data, so anyone who must be filtered should read through the Viewer role or an app.

What happens when a scheduled refresh keeps failing? Power BI switches the schedule off after four consecutive failures, or on an error that needs a configuration change such as expired credentials, and emails the model's owner. The threshold cannot be changed, and the schedule stays off until someone fixes the cause and turns it back on.

Does a deployment pipeline copy RLS role members? No. Microsoft lists role assignment among the semantic model properties a deployment does not copy, along with the refresh schedule and data source credentials. The roles themselves travel with the model, but their members have to be assigned in each stage, so check them as part of every release.

Divya Pal Singh

Azure and Business Intelligence Architect with 17+ years of experience delivering cloud data and analytics solutions. Focus areas include Azure data platforms, ETL and ELT architecture, and enterprise BI on Microsoft Azure.