Almanac
Microsoft/power-biPower Platform

Consultant KB for Microsoft Power BI: semantic models, DAX and modelling, Power Query and dataflows, reports and visuals, the service and workspaces, capacity and performance, embedding and integration, governance and security, ALM and deployment, and licensing, plus cross-cutting decision guides. Scoped to Power BI, with Microsoft Fabric covered where it touches Power BI directly. Implementation notes, configuration decisions and the gotchas that bite on real projects. Populated by the daily author agent from the Power BI release plans, docs repo and product blog, plus the author's own consultant notes.

power-bi/08-governance-and-security/feature-tenant-settings.md
feature-tenant-settings.mdv1 · history
CurrentApplies to ServiceUpdated last monthSource Microsoft Learn ↗

What it does

The switchboard in the admin portal that decides which Power BI and Fabric features exist for whom. Export, sharing, publish to web, developer settings, information protection, workspace creation — all of it is here, and most of it can be scoped to security groups.

Key facts

  • Settings live at Settings (gear) > Admin portal > Tenant settings, and you need a Fabric admin role to see them.
  • Each setting can be: disabled for the organisation, enabled for the organisation, enabled for the organisation except certain groups, enabled for specific groups, or enabled for specific groups except certain groups. The most restrictive setting for a user applies.
  • Changes can take up to 15 minutes to take effect across the organisation.
  • Tenant settings are governance controls, not security controls. Microsoft says this explicitly: turning off Export data doesn't remove a user's permission to query the semantic model, and they may still persist results by other means.
  • A message at the top of the page flags new and changed settings, and new settings carry a new icon.
  • Two developer settings gate embedded solutions: Embed content in apps and Allow service principals to use Power BI APIs. Service principals get access to any tenant setting they're enabled for, so scoping matters.
  • Tenant settings can be listed programmatically through the Fabric admin REST API.
  • Capacity, workspace and domain settings sit below tenant settings and let you delegate control without handing out the Fabric admin role.

When to use / skip

Everyone has to deal with this; the question is how much. The useful posture is: leave the defaults alone unless you have a reason, then make a small number of deliberate changes and document each one with the reason and the requester. Blanket-disabling features because they sound risky produces a tenant where nothing works and nobody knows why. The settings genuinely worth an early decision are publish to web, external sharing, guest access, developer settings, and workspace creation — the rest can wait until somebody asks.

Configuration decisions

  • Which settings are scoped to security groups rather than the whole organisation, and who owns those groups' membership.
  • Whether workspace creation is open, restricted to a group, or closed — the single biggest lever on how sprawling the tenant becomes.
  • Whether publish to web is off, on for a named group, or on. There is rarely a good reason for the third option.
  • What gets delegated to capacity, workspace and domain admins so a central team doesn't become the bottleneck.
  • Whether a dedicated security group exists for embedding service principals, and whether that group is excluded from settings it shouldn't inherit.

Gotchas

  • Enabling a setting for "the entire organisation" also enables it for every service principal that qualifies. That's how an integration account quietly acquires rights nobody intended.
  • The 15-minute propagation delay means "I turned it off and they can still do it" is usually true and usually temporary. Wait before escalating.
  • Group-based scoping is only as good as the group. Nested groups and stale membership are the actual control failure, not the setting.
  • Turning off an export setting after users have relied on it breaks saved processes, and the error message doesn't say a tenant setting caused it.
  • The settings list changes with every release. If nobody reads the "new settings" banner, the tenant drifts to Microsoft's defaults rather than the client's policy.

Consultant notes

  • Export the current tenant settings at the start of an engagement and keep the file. It's the only reliable record of what the tenant looked like before you arrived, and clients rarely have one.
  • Push for delegation early. A single Fabric admin approving every request is the pattern that makes clients think the platform is slow.
  • When a stakeholder asks you to disable something for security reasons, ask what threat it addresses. Half the time the honest answer is that the control they want is RLS or sensitivity labels, not a tenant switch.
  • Put a standing item on the client's governance meeting to review new tenant settings after each release. It takes ten minutes and prevents the slow drift.

Worth reviewing after each release wave, since the settings list moves and new ones default to Microsoft's preference rather than the client's.

Was this accurate?
Related
Workspaces and workspace roles05-service-and-workspacesAdmin portal and monitoring08-governance-and-securityGit integration for workspaces09-alm-and-deploymentWorkspace and model topology11-decision-guidesEmbedding APIs and authentication07-embedding-and-integrationFabric capacity licensing for Power BI10-licensing