Administer Power BI and Microsoft Fabric: tenant settings, workspaces, gateways, and refresh

How can you administer Power BI and Microsoft Fabric as more workspaces, reports, data sources, and gateways are created? The central approach is separating tenant governance, workspace responsibilities, and technical data operations. Tenant settings define which features are available; workspace roles control collaboration; gateways and credentials enable data access; monitoring and lifecycle ensure that content continues to function even after personnel changes or source modifications.

Embedding finished reports in SharePoint and Teams is covered in the post Embed Power BI in SharePoint and Teams. This article focuses on the administrative platform level. For process data flowing from SharePoint, Power Apps, and Power Automate into reports, Power Platform with SharePoint provides the business context.

Administration areas

Area: Tenant Settings

Task: Control features and target audiences

Typical risk: Tenant-wide enablement without a risk assessment

Area: Workspaces

Task: Content, roles, and lifecycle

Typical risk: Orphaned workspaces

Area: Licenses and capacities

Task: Enable creation, sharing, and consumption

Typical risk: Unexpected access or cost issues

Area: Gateways

Task: Access to local data sources

Typical risk: Single point of failure

Area: Credentials

Task: Authentication at data sources

Typical risk: Personal account expires

Area: Refresh

Task: Freshness of semantic models

Typical risk: Reports show outdated data

Area: Deployment

Task: Development, test, and production

Typical risk: Direct changes without rollback

Area: Audit and monitoring

Task: Track usage and changes

Typical risk: Errors remain undetected

Understand Power BI and Fabric

Power BI is part of the Microsoft Fabric platform and is managed in part via the Fabric Admin Portal. Tenant settings can affect both Power BI and Fabric features. Administrators should therefore check whether a setting affects only BI usage or additional Fabric workloads.

Not every visible tenant setting is a hard security boundary. Microsoft notes, for example, that some UI or feature settings support governance but do not replace existing data permissions. Data access must continue to be secured via workspace, item, semantic model, and source.

Role model

For workspace roles, the highest effective permission from all group memberships takes precedence when permissions overlap. For anything beyond simple viewing and interacting, Pro or PPU rights are typically required. Roles and licensing model must therefore always be reviewed together.

Tenant administration

Fabric or Power BI administrators manage tenant-wide settings, capacities, workspace views, and governance functions. This role should not be assigned broadly to all report developers.

Workspace roles

Power BI uses roles such as Admin, Member, Contributor, and Viewer. They differ in management, publishing, and consumption.

Basic principles:

• Workspace admins only for responsible operators,
• Developers via Member or Contributor aligned with the process,
• Consumers preferably via Viewer or app access,
• Groups instead of many individual users,
• at least two active workspace administrators for critical areas.

Disabling an Entra user does not automatically remove all saved workspace access entries. Offboarding must explicitly account for Power BI.

Workspace strategy

Workspaces should not be created spontaneously per report. A sensible model is based on ownership, data area, and deployment:

• Business team workspace,
• centrally managed enterprise BI workspace,
• development, test, and production separated,
• separate data or semantic model workspaces from reporting where needed,
• Personal experiments in My Workspace only without production dependencies.

For every production workspace:

• Business owner,
• Technical operator,
• Administrator group,
• Data classification,
• Capacity and licensing model,
• Deployment path,
• Support contact,
• Archival date.

Manage tenant settings with control

Tenant settings can often be applied specifically to security groups and do not always take effect immediately. A realistic rollout accounts for staggered processing and verifies the effect with test users. The key assessment remains: These settings support governance but do not replace data permissions at the workspace, item, or source level.

Tenant settings can often be enabled for the entire organization or selected security groups. New features should not be turned on globally immediately.

Review process:

1. Document purpose and affected function.
2. Assess data and compliance impact.
3. Check licensing and capacity impact.
4. Define pilot group.
5. Enable setting only for this group.
6. Monitor audit, usage, and support cases.
7. Make decision on broader rollout.

Especially relevant are settings for:

• Creating workspaces,
• external sharing and guest access,
• export and download,
• Publish to web,
• service principals and admin APIs,
• Fabric workloads,
• Copilot or AI features,
• custom visuals.

"Publish to web" and similar public sharing features require particularly strict assessment because they can make content accessible outside normal user permissions.

Licensing and capacity model

Creators and recipients require different licenses depending on the sharing and capacity model. Power BI Pro, Premium Per User, and Fabric or Premium capacities offer different options. A PPU workspace is not equivalent to a dedicated Premium or Fabric capacity. This distinction should be explicitly tested before any broad distribution.

Before deployment, verify:

• Who creates and publishes?
• Who consumes?
• Is the workspace in an appropriate capacity?
• Do external guests require their own licenses?
• Are PPU features used?
• What costs arise with increasing user numbers?

Licensing assumptions should be checked against current Microsoft documentation before any major rollout.

On-premises data gateway

Only Gateway administrators can create new data sources at the gateway. Additionally, the respective user or service must be authorized at the specific data source. After republishing the semantic model, it is often necessary to recheck whether the gateway and data source are still correctly assigned.

A gateway connects the cloud service with local data sources. For production use, no single workstation should serve as an unattended gateway host.

A robust gateway concept includes:

• servers or suitable permanent hosts,
• gateway clusters for availability,
• multiple administrators,
• documented recovery key,
• patch and update procedures,
• service account and data source credentials,
• network sharing with Microsoft services,
• monitoring of service and resources,
• recovery test.

Match data source exactly

Gateway assignment can fail if server or data source names are specified differently in the semantic model than in the gateway data source. Hostname, instance name, and optionally IP must be consistent.

Credentials and ownership

Scheduled refresh often depends on stored credentials. If personal accounts are used, a password change, MFA modification, or departure can stop the refresh.

For production data sources:

• select an appropriate identity model,
• assign least-privileged database rights,
• appoint multiple gateway administrators,
• document credential rotation,
• monitor secret or certificate expiry,
• maintain a list of responsible persons for each data source.

Manage data updates

Refresh itself also depends on the capacity model. Frequency, parallel processing, and possible pauses for scheduled updates differ by capacity and usage. Responsible parties should therefore monitor error messages, usage data, and visit data together.

Power BI distinguishes various connection and update models. For imported data, a refresh loads new data into the semantic model. DirectQuery or Live Connection behave differently and may also require a gateway.

Document each production refresh:

• semantic model,
• source system,
• Connection mode,
• Gateway and data source,
• Schedule,
• Expected duration,
• Business freshness requirement,
• Notification recipient,
• Fallback on failure.

Refresh monitoring

A report can be accessible yet still display outdated data. Monitoring must therefore check the last successful refresh and the business freshness of the data.

In case of errors:

1. Open Refresh History.
2. Save the error timestamp and message.
3. Check Gateway status.
4. Verify credentials.
5. Check source system availability.
6. Investigate schema or file path changes.
7. Test Desktop Refresh with a comparable configuration.
8. Start manual refresh after correction.
9. Validate the business data state.

Typical error scenarios

Refresh works in desktop but not in the service

Possible causes:

• Gateway is missing or incorrectly assigned,
• Data source uses a different hostname,
• Credentials are missing,
• dynamic or unsupported source,
• local data protection or network settings differ.

Diagnosis: Power BI Desktop on the gateway host can help narrow down the data source and network. Then check gateway mapping and semantic model settings.

Report shows no current data, although refresh was "successful"

• source itself is not current,
• query filters out new data,
• timezone or incremental logic is incorrect,
• report uses a different semantic model,
• cache or tile has not been updated yet.

Action: compare the business data value in the source, semantic model, and report.

Workspace has only one administrator

When a user leaves, no one can manage roles, gateway binding, or deployment.

Correction: Admin access via groups and at least two responsible persons. Include offboarding in the user lifecycle.

Free user cannot open report

Workspace, capacity, role, and licensing model do not match the sharing permissions.

Diagnosis: Content and underlying semantic model must reside in an appropriate capacity; check recipient role and licensing terms.

Tenant setting was activated globally

A new export or sharing feature is unexpectedly available to all users.

Rollback: Set the setting back to the previous state and introduce it in the future via a pilot security group. Investigate separately any content already exported or publicly shared.

Content lifecycle and deployment

Production content should not be developed exclusively in My Workspace or directly in production.

A controlled workflow:

1. development in your own workspace,
2. Version source code and PBIX/PBIP files and parameters,
3. Review and test,
4. Use a deployment pipeline or automated process when appropriate,
5. Acceptance in test,
6. Release to production,
7. Document the release,
8. Keep the previous version for rollback.

Deployment pipelines move metadata between stages but do not replace validation of data sources, credentials, and environment parameters.

External sharing

External users require appropriate Entra B2B configuration, Power BI tenant settings, and licensing. Access to a report may also imply access to underlying data models or shared content.

Before sharing:

• Business purpose,
• Data classification,
• Recipient identity,
• Licensing,
• Expiration date,
• Export rights,
• Establish regular access reviews.

Regular operations plan

• Workspaces without two admins,
• Personal workspaces with production dependencies,
• Failed refreshes,
• Gateways offline or outdated,
• Data sources without owners,
• external sharing,
• tenant setting changes,
• unused or duplicate semantic models,
• capacity utilization,
• orphaned deployment pipelines and apps,
• license and service changes.

When reports need to be visible in M365 workspaces, embedding Power BI in SharePoint and Teams connects directly. For data flows and DLP on the low-code side, administering Power Platform complements the governance view.

How to keep the BI platform reliable despite a growing number of reports

Power BI and Fabric become manageable when tenant settings are introduced in groups, workspaces have clear ownership, and data sources are treated as technical operations objects. Gateways have redundancy, refreshes are monitored, and content goes through development, test, and production. This keeps reports current and accessible, even when developers, passwords, or source systems change.