Microsoft Purview DLP Restrict Access for Fabric: Guest Controls, Coverage Limits and Admin Setup

For Fabric administrators, the important distinction is between knowing sensitive information exists and controlling who can reach it. A warning asks someone to act; an access restriction changes what they can do. But the practical details matter: “guest” has a precise identity definition, workspace administrators retain a remediation route, and some data formats and refresh scenarios fall outside documented evaluation support.

What changed—and how to read the release status​

Microsoft’s roadmap metadata for item 422501 lists the feature as Launched, with general availability recorded as October 2026. Its scope covers the web experience in the Worldwide standard multi-tenant cloud, and its description explicitly includes both semantic models and lakehouses. The change adds access enforcement to the existing auditing and policy-tip capabilities.

There is an important documentation qualification. Microsoft Learn’s DLP overview in the available evidence still describes Restrict access as a preview feature. Consequently, the roadmap’s October general-availability designation should not be presented as a deployment-completion guarantee for every tenant, nor should the documentation be described as independently confirming that transition. Microsoft also cautions that roadmap release information can change.

The historical preview date needs similar care. The roadmap metadata records April 2024, but Microsoft’s November 2024 security announcement describes extending the Restrict access action to Fabric semantic models at that time. That announcement separately discusses earlier lakehouse DLP detection and notification capabilities. These are distinct milestones: lakehouse scanning support and access enforcement are not interchangeable announcements. The metadata alone therefore does not establish when both item types first received the complete restriction capability.

This is a cloud-service governance change, not a Windows cumulative update. The relevant administrative boundaries are Fabric workspaces, capacity, identities, policy conditions, and supported data—not a Windows build number or KB installation. Microsoft’s configuration documentation places the work in the Purview portal and scopes the policy to Fabric and Power BI workspaces.

What Restrict access actually enforces​

Microsoft Learn identifies three principal Fabric DLP actions: notifying users through policy tips, generating alerts, and restricting access. Administrators define the conditions and choose the response when a supported item matches. Conditions can include sensitivity labels and supported sensitive information types.

The restriction’s audience is particularly important:

Microsoft’s Fabric troubleshooting guidance supplies these distinctions and explains that organizational policies can override ordinary item permissions and workspace settings. An existing sharing permission is therefore not an exemption from an applicable DLP restriction.

That makes the feature an access-enforcement mechanism, rather than simply a stronger-looking alert. It also means administrators should avoid interpreting “block all users” as an absolute lockout: the documented workspace-administrator exception is operationally significant. Someone must still be able to investigate a false positive or remove information that should not have been added.

“Outside the organization” means an Entra user type​

The most easily overlooked detail is how Purview identifies external users.

Microsoft defines organizational members for this purpose as accounts with UserType = Member. That includes users signing in with external accounts when their tenant user type is Member. Accounts with UserType = Guest are treated as external, and the setting Block only people outside your organization applies to those guests.

The practical implication is straightforward: a contractor’s employment relationship or email domain does not, by itself, tell an administrator whether guest-only enforcement will block that account. The relevant tenant classification must be checked.

Consider a hypothetical partner collaboration workspace. Two external collaborators could receive different treatment if one account is classified as Guest and the other as Member. That follows from Microsoft’s documented identity rules; it is not evidence of inconsistent enforcement. Before relying on guest-only restrictions, administrators should review the actual account types used for partners and contractors.

The takeaway: identity housekeeping is part of the protection design, not an unrelated directory-cleanup exercise.

Evaluation timing can determine whether a test works​

For semantic models, Microsoft documents four evaluation triggers:

• Publishing.
• Republishing.
• On-demand refresh.
• Scheduled refresh.

However, evaluation does not occur for those events when a service-principal-authenticated account initiates them, or when the semantic model owner is a service principal. Both exceptions matter when assessing automated publishing and refresh workflows.

Lakehouses follow a different pattern. Fabric DLP evaluates an item when its data changes, including new data arriving, a source being connected, tables being added, or existing tables being updated. Administrators should therefore validate semantic models and lakehouses separately rather than assuming one successful test proves both paths.

A useful testing recommendation, based on those documented triggers, is to record the item type, ownership, initiating identity, and data-change event alongside the result. If a semantic model refreshed without a policy response, those details help distinguish a supported evaluation that found no match from a scenario in which evaluation did not run.

Microsoft also warns that onboarding a new tenant can take several hours, depending on the number of supported workspaces. An immediate absence of alerts is not, by itself, a complete diagnosis.

Check the coverage boundaries before enabling enforcement​

Restrict access depends on the underlying Fabric DLP support. A powerful action cannot compensate for a data source that the evaluation does not support.

Microsoft’s overview documents several significant boundaries:

• Capacity: Policies apply to workspaces hosted in Fabric or Premium capacities.
• Semantic models: Sample semantic models, streaming datasets, DirectQuery models, and live-connection models are unsupported. The DirectQuery limitation also includes mixed-storage models combining imported data with DirectQuery.
• Fabric data: DLP applies to data in Delta-format tables, rather than indiscriminately covering every file in a lakehouse.
• Classifiers: Exact data match, trainable classifiers, credential classifiers, and named entities are unsupported. Selecting an unsupported advanced classifier can return no results even when matching information exists.
• Region: Fabric DLP is not supported in China North.

The Delta limitations go deeper than the file-format label. Microsoft lists unsupported types including Binary, timestamp_ntz, Struct, Array, List, Map, Json, Enum, Interval, and Void. It also lists data using LZ4, Zstd, and Gzip compression as unsupported. Delta tables are treated as text files for scanning considerations.

These are general Fabric DLP limitations, not newly introduced restrictions unique to roadmap item 422501. Their significance is nevertheless greater when detection drives an access decision: administrators need to understand both where enforcement can occur and where a lack of detection says little about the data.

Prepare a scoped policy deployment​

Microsoft’s configuration guide identifies eligible policy-creation role groups, including Compliance administrator, Compliance data administrator, Information Protection, Information Protection Admin, and Security administrator. It also lists qualifying administrator licensing options: Microsoft 365 E5, E5 Compliance, E5 Information Protection & Governance, or Purview capacities. Confirm those prerequisites before troubleshooting a missing policy-creation option.

The documented configuration entry points are:

1. Open the Purview DLP policies page and select + Create policy.
2. Choose Custom, then Custom policy.
3. Enter a descriptive policy name.
4. Proceed past Assign admin units; these are not supported for Fabric DLP.
5. Select Fabric and Power BI workspaces.
6. Use Edit to specify included or excluded workspaces; otherwise, the default scope is all workspaces.
7. Choose Create or customize advanced DLP rules, then Create rule.

Within the rule design, define supported detection conditions, select the appropriate restriction audience, and decide whether policy tips and alerts should accompany enforcement. Microsoft’s overview confirms that these are configurable responses to a policy match.

For deployment validation, a sensible administrator-created checklist is:

• Use a limited workspace scope first.
• Test with known Member and Guest accounts.
• Confirm that the intended evaluation trigger occurred.
• Check that the expected users lose access while administrators retain their documented remediation path.
• Verify that alerts and user-facing explanations provide enough information to investigate.

This checklist is practical analysis derived from Microsoft’s documented behavior, not a claim of hands-on testing. It also helps avoid a misleading result from testing only with a workspace-administrator account that is exempt from the broad DLP block.

Capacity planning deserves attention too. Microsoft states that DLP evaluation workloads affect capacity consumption. Its overview does not establish a universal per-scan price, so administrators should not assume that broader scanning has no resource or billing implications.

What users will see when a policy matches​

Where notifications are enabled, Fabric can mark an affected item and expose policy details in a side panel. Semantic models show a policy tip on their details page. Lakehouses show an indication in the header while in edit mode, with a flyout providing further information. Hiding a policy tip does not remove the underlying finding; it appears again on a later visit.

Access restrictions can be less self-explanatory. Microsoft documents items disappearing from workspace lists or the OneLake catalog, direct links producing permission or missing-artifact messages, and dashboard tiles failing when their underlying data is restricted. Other tiles can continue rendering normally.

Those symptoms do not uniquely identify DLP. Purview protection policies can produce similar experiences, while manually revoked permissions and workspace-role changes are separate possible causes. Help desks should therefore treat a vanished item as an access investigation—not immediately as deletion, corruption, or a service outage.

Investigate and restore access without defeating the policy​

Microsoft recommends that affected users contact their workspace administrator. The documented investigation starts with the item’s Manage Permissions page:

1. Inspect the affected user’s permission state.
2. If it shows User is blocked, an organizational security policy revoked access.
3. Review recent changes. Label changes can point toward a protection policy; item updates or sensitive-data findings can point toward DLP.
4. If the blocked state is absent, investigate ordinary permission removal or workspace-role changes instead.

These clues guide investigation; they do not replace identifying the actual policy responsible.

For a DLP false positive, Microsoft says a workspace administrator can override the policy when confident the detection is incorrect, with justification available to the compliance team. Where sensitive information was mistakenly added, removing it triggers reevaluation and can lift the restriction when the offending content is no longer detected. Microsoft cautions that remediation actions are audited and must not compromise security or compliance.

The broader lesson is that enforcement needs an operating procedure as much as a policy setting. Decide who investigates, who approves exceptions, and how users receive an explanation before expanding coverage.

Purview’s Restrict access action is a meaningful addition for semantic models and lakehouses because it connects a sensitive-data finding to an access consequence. Its usefulness, however, depends on getting the surrounding details right: supported data, evaluation triggers, Entra account types, workspace scope, and a defensible remediation process. The sensible goal is not simply more blocked items—it is predictable protection that administrators can explain and validate.