Essential Fabric Tenant Settings
Configure essential Microsoft Fabric tenant settings for security, governance, and optimal performance. Admin guide for enterprise Fabric environments.
Fabric tenant settings control which features and capabilities are available across your entire organization. These settings are the primary governance control plane for Microsoft Fabric—they determine who can create workspaces, what data can be exported, which AI features are enabled, and how external sharing works. Misconfiguring tenant settings is the most common cause of both security incidents and adoption friction in Fabric deployments. Getting them right requires balancing governance with usability, which is why most organizations benefit from a phased approach rather than enabling or disabling everything at once. Our Microsoft Fabric consulting team configures tenant settings for enterprises across healthcare, financial services, and government sectors where compliance requirements add additional complexity.
I have been configuring Microsoft admin portals for over 25 years—from SharePoint Central Administration to Power BI Admin to the Fabric Admin portal. The consistent lesson across every platform is that default settings are designed for broad accessibility, not enterprise governance. Out of the box, Fabric enables features that most organizations should restrict, and restricts features that most organizations should enable. A 2-hour tenant settings review at the start of your Fabric deployment prevents months of security remediation and governance firefighting later.
Accessing and Understanding Tenant Settings
Tenant settings are configured in the Fabric Admin Portal (admin.fabric.microsoft.com) under Tenant settings. Only users with the Fabric Administrator, Power Platform Administrator, or Global Administrator role can modify these settings.
Settings fall into five configuration states:
| State | Meaning | When to Use |
|---|---|---|
| Enabled for the entire organization | Every user in the tenant can use the feature | Low-risk features with broad value |
| Enabled for specific security groups | Only members of designated Azure AD groups | Features requiring governance (e.g., workspace creation) |
| Disabled for the entire organization | No users can use the feature | High-risk features or features not needed |
| Enabled except specific security groups | Everyone except excluded groups | Features enabled by default with specific exclusions |
| Delegated to workspace admins | Workspace-level control | Features where workspace-level governance is appropriate |
Best practice: Never use "Enabled for the entire organization" for sensitive features. Always scope to specific security groups so you have explicit control over who can do what.
Critical Tenant Settings: Security and Governance
Workspace Settings
| Setting | Recommended Configuration | Rationale |
|---|---|---|
| Create workspaces | Specific security groups only | Prevents workspace sprawl; only platform admins and domain leads create workspaces |
| Use semantic models across workspaces | Enabled | Allows shared datasets, reducing duplication |
| Block users from reassigning personal workspaces | Enabled | Prevents shadow IT in personal workspaces |
Restricting workspace creation is the single most impactful governance setting. When every user can create workspaces, you end up with hundreds of ungoverned workspaces within months. Our workspace design guide covers the organizational patterns that make restricted creation practical.
Export and Sharing Settings
| Setting | Recommended Configuration | Rationale |
|---|---|---|
| Export to Excel | Enabled (specific groups) | Most users need this; restrict in high-security environments |
| Export to CSV | Enabled (specific groups) | Same as Excel export |
| Export to PDF/PowerPoint | Enabled (specific groups) | Common for executive reporting |
| Export underlying data | Disabled (or specific groups only) | Prevents bulk data extraction; major security risk |
| Print reports | Enabled | Low risk, but consider for classified data environments |
| Allow downloads from custom visuals | Disabled | Custom visuals can be used to exfiltrate data |
**Export underlying data** is the most dangerous default-enabled setting. When enabled, any user with report access can export the complete underlying dataset—potentially millions of rows including data they cannot see in the visual due to aggregation. Disable this immediately for any environment handling sensitive data. This is a frequent audit finding in healthcare and financial services compliance reviews.
External Sharing and Guest Access
| Setting | Recommended Configuration | Rationale |
|---|---|---|
| Share content with external users | Specific security groups | Prevents accidental external sharing |
| Allow Azure AD B2B guests | Enabled (specific groups) | Required for partner/vendor collaboration |
| Show content to external guests | Specific security groups | Control which content external users see |
| Allow guest users to edit and manage content | Disabled | Guests should be view-only in most cases |
| Publish to web | Disabled | Makes content publicly accessible on the internet—almost never appropriate for enterprise data |
Publish to web is the most commonly misconfigured setting I encounter. It literally creates a public URL that anyone on the internet can access without authentication. I have seen organizations accidentally publish financial dashboards, customer data, and HR metrics to the public internet because this setting was enabled and a well-meaning user clicked "Publish to web" thinking it meant "publish to the Power BI service." Disable this unless you have a specific, documented public data use case.
AI and Copilot Settings
| Setting | Recommended Configuration | Rationale |
|---|---|---|
| Users can use Copilot and AI features | Specific security groups | Phase rollout: start with power users, expand gradually |
| Allow AI features to access your data | Specific security groups | Controls whether AI can process your organizational data |
| Data sent to Azure OpenAI is not stored | Verify enabled | Required for compliance—ensures prompts are not retained |
| Copilot for Power BI | Specific security groups | Controls report-building Copilot access |
| Copilot in Fabric items | Specific security groups | Controls notebook/SQL/pipeline Copilot access |
AI settings deserve particular attention because they involve sending organizational data to language models. While Microsoft guarantees that data sent to Azure OpenAI is not used for model training and is not stored beyond the session, organizations in regulated industries may have additional restrictions on data processing by AI systems. Document your AI data processing decisions for compliance evidence.
Developer and Integration Settings
| Setting | Recommended Configuration | Rationale |
|---|---|---|
| XMLA endpoint | Enabled for specific groups (Read or Read/Write) | Enables external tools, ALM Toolkit, Tabular Editor |
| Allow service principals | Enabled for specific groups | Required for automated CI/CD pipelines |
| Embed content in apps | Enabled for specific groups | Required for embedded analytics |
| Push datasets | Specific security groups | Controls who can push data via REST API |
| Template apps | Specific security groups or disabled | Control app distribution |
| Execute queries and scripts on datasets | Enabled for developers | Required for DAX Studio and diagnostic tools |
XMLA endpoint configuration is critical for mature Power BI development practices. Without it, teams cannot use Tabular Editor, DAX Studio, ALM Toolkit, or automated deployment scripts. Enable Read access for all developers and Read/Write access for senior developers and CI/CD service principals only.
Capacity and Resource Settings
| Setting | Recommended Configuration | Rationale |
|---|---|---|
| Users can try Fabric paid features | Disabled | Prevents uncontrolled capacity consumption |
| Users can create trial capacities | Disabled | Trials create ungoverned resources |
| Auto-scaling | Enabled with maximum CU limit | Prevents runaway costs from unexpected workloads |
| Workload management | Configure per capacity | Allocate CU budgets per workload type |
See our capacity planning guide for detailed guidance on capacity-level configuration that complements these tenant settings.
Information Protection Settings
| Setting | Recommended Configuration | Rationale |
|---|---|---|
| Sensitivity labels | Enabled | Classifies content (Confidential, Internal, Public) |
| Mandatory label policy | Enabled | Requires users to label content before sharing |
| Label inheritance from data sources | Enabled | Automatically applies upstream labels to downstream content |
| Default label for new content | Internal (or your equivalent) | Ensures nothing is unlabeled |
| Allow users to apply lower sensitivity labels | Disabled | Prevents downgrading classification |
Sensitivity labels integrate with Microsoft Purview Information Protection and propagate across the Fabric ecosystem. When a Lakehouse table is labeled "Confidential," that label follows the data into Power BI reports, exports, and shared content. This is essential for GDPR compliance and data loss prevention.
Tenant Settings Configuration Checklist
Implementing tenant settings is a phased process, not a one-time event:
Phase 1: Day 1 Security (Before any users access Fabric)
| Priority | Setting | Action |
|---|---|---|
| P0 | Publish to web | Disable |
| P0 | Export underlying data | Disable or restrict to security group |
| P0 | Create workspaces | Restrict to admin security group |
| P0 | Share with external users | Restrict to security group |
| P0 | Custom visual downloads | Disable |
| P0 | Users can try paid features | Disable |
Phase 2: Governance Foundation (Week 1-2)
| Priority | Setting | Action |
|---|---|---|
| P1 | Sensitivity labels | Enable with mandatory labeling |
| P1 | XMLA endpoint | Enable Read for developers, Read/Write for senior devs |
| P1 | Service principals | Enable for CI/CD groups |
| P1 | Copilot features | Enable for pilot group only |
| P1 | Export to Excel/CSV/PDF | Enable for appropriate groups |
Phase 3: Scaling Governance (Month 2-3)
| Priority | Setting | Action |
|---|---|---|
| P2 | Workspace creation | Expand to domain leads |
| P2 | AI features | Expand Copilot to broader user base |
| P2 | External sharing | Enable for collaboration scenarios |
| P2 | Embed content | Enable for application teams |
| P2 | Delegation to workspace admins | Enable for mature workspace owners |
Monitoring and Auditing Tenant Settings
Tenant settings are not set-and-forget. Monitor and review regularly:
| Monitoring Activity | Frequency | Tool |
|---|---|---|
| Review setting changes | Weekly | Audit log (filter for TenantSettingChanged events) |
| Verify security group membership | Monthly | Azure AD access reviews |
| Test export restrictions | Quarterly | Manual testing by security team |
| Compliance audit | Annually | Full tenant settings review against policy |
| External sharing audit | Monthly | Review shared content with external users |
Use the Power BI REST API to programmatically export current tenant settings for documentation and compliance evidence. This is especially important for organizations undergoing SOC 2 or ISO 27001 audits where evidence of access controls is required.
Common Tenant Settings Mistakes
Mistake 1: Leaving defaults unchanged Default settings prioritize accessibility over security. Review every setting before enabling Fabric for production use.
Mistake 2: Over-restricting everything Locking down all features prevents adoption. Users will find workarounds (Shadow IT) that are even less secure than properly governed Fabric usage. Balance governance with usability.
Mistake 3: Not using security groups Configuring settings for "the entire organization" removes granular control. Always use security groups, even if the group currently contains all users—it gives you the ability to restrict later without changing the setting.
Mistake 4: Ignoring audit logs Tenant settings changes are logged in the unified audit log. Review these logs weekly to detect unauthorized changes or unexpected configuration drift.
Mistake 5: No documentation Undocumented tenant settings lead to "why is this disabled?" conversations that waste time and may result in incorrect changes. Document every setting, its rationale, and the approving stakeholder.
Getting Started with Tenant Settings
- Export current settings using the Admin API for baseline documentation
- Implement Phase 1 (P0) settings immediately—these are security-critical
- Create security groups in Azure AD for each permission tier
- Implement Phase 2 settings in the first two weeks
- Schedule quarterly reviews of all settings against business requirements
- Document everything in your governance framework
For organizations that need tenant settings configuration, our Fabric consulting team provides governance assessments, security configuration, and ongoing compliance monitoring. We also integrate tenant settings with your broader Power BI governance framework for comprehensive platform governance. Contact us to discuss your Fabric governance needs.
Frequently Asked Questions
Who can change Fabric tenant settings?
Only Fabric administrators and Global administrators can modify tenant settings. These settings affect all users in the organization, so changes should be made carefully and documented.
Can I apply settings to specific groups?
Yes, many tenant settings can be scoped to specific security groups. This allows piloting features with selected users before organization-wide rollout.