A report in a Power BI workspace with outbound access protection (OAP) turned on can now query a semantic model in a different workspace, as long as a workspace admin has explicitly allowed that destination. Microsoft announced the change on November 5, 2026, and it’s still a preview. So test it now, but don’t make it a dependency for critical reporting yet.
What changed in Power BI outbound access protection?
OAP is a Fabric workspace setting that restricts where the workspace’s data is allowed to go. When Microsoft first previewed it for Power BI reports in June, a report in a protected workspace could only use a semantic model sitting in its own workspace. Microsoft’s announcement says customer feedback called that too restrictive.
Now the report can reach a model in another workspace if an admin has added an exception policy for that destination. Blocking is still the default. When someone opens a report, Power BI checks the report workspace’s policy before rendering anything. If an exception covers the model’s workspace, the report connects. If not, the connection is blocked and the report doesn’t open.
The admin sets this up in the report workspace’s settings:
- Under Outbound networking, choose Add new cloud connection rule.
- Set Connection Kind to Power BI Semantic Model.
- Pick the model’s workspace under Workspace exception.
- Select Add, then Save.
Why does this matter to a smaller business?
Microsoft points to a common Power BI setup: one central team manages shared semantic models in a single workspace, while business teams build their own reports in separate workspaces. In a smaller company, that “central team” might be one analyst or an outside partner. The pattern is the same, though. One governed model, many reports.
Without an exception
- Someone opens the report
- Power BI checks the report workspace policy
- No exception covers the model workspace
- Connection blocked, report doesn't open
With an exception
- Admin adds the exception rule
- Someone opens the report
- Power BI checks the report workspace policy
- Exception covers the model workspace
- Report connects and visuals render
Source: Power BI
Under the June rules, you had to pick between locking down outbound data flow and keeping that separation of ownership. The new exception policy lets you keep both. The exception is tied to the destination workspace, not to each report, so a new report that uses an already-approved model doesn’t need its own rule. Nothing has to be consolidated, either: reports and models can stay in the workspaces they’re in now.
What should you do now?
If you use Fabric workspaces, or plan to lock them down, a small test is cheap. Start with a non-critical workspace pair and walk through the same sequence Microsoft describes: confirm the report gets blocked, add the exception, then confirm it loads.
A few practical points to cover in that test:
- List which reports pull from semantic models in other workspaces. Those are the ones OAP would affect.
- Enable OAP on both the report workspace and the model workspace. Microsoft says you need both.
- Ask your workspace admin to confirm the report workspace meets the OAP prerequisites.
- Allow about 15 minutes for a policy change to take effect before you decide it failed.
What should you wait on?
Hold off on rolling OAP out across every workspace, or restructuring your workspaces around it. It’s a preview, so treat it as a trial and check Microsoft’s documentation before you commit. A blocked report simply doesn’t open, which is a bad surprise on the morning of a board meeting.
Also don’t assume the exception does more than it says. It only allows the report-to-model connection. The semantic model stays subject to its own OAP controls, and its connections to cloud databases, gateway-based on-premises systems, lakehouses and warehouses are still checked against the model workspace’s data connection rules. If your model pulls from several sources, those rules need their own review.
How would you evaluate it for your reporting?
Start with an inventory, not a switch. A business intelligence review would map which workspaces hold shared models, which hold reports, and which data sources each model touches. Then it would ask a simple question for each pair: should this report be allowed to reach this model, and should the model be allowed to reach those sources?
That gives you a short list of approved destinations, which is exactly what the exception policy needs. If the list turns out long or unclear, that tells you something useful about your workspace sprawl before OAP even enters the picture.
What should you do next?
Pick one report and its shared semantic model, put them in separate workspaces in a test environment, and run the block-then-allow sequence once. Write down who approved the exception, how long it took to take effect, and what broke along the way. That one-page record will tell you whether the preview fits your setup and what you’d need before using it in production. Want help with this? See our work on Business intelligence and Power BI consulting, or book a meeting with our team.
Frequently asked questions
Do the report and its semantic model have to live in one workspace?
No. The exception policy exists so the report and model can stay in separate workspaces. A workspace admin allows the model’s workspace as a destination, and the report binding itself doesn’t change.
Does an exception open up the semantic model’s data sources too?
No. The model’s own OAP controls still apply. Its connections to cloud databases, gateways, lakehouses, warehouses and other sources are evaluated against the model workspace’s data connection rules.
How long does a policy change take to apply?
Microsoft’s guidance is that a saved policy may need roughly 15 minutes before it’s in effect. If a report is still blocked right after you save the rule, wait before troubleshooting further.
Related reading
Sources
- Power BI reports support OAP exceptions for semantic models in separate workspaces (Preview), Power BI, 2026-11-05
Researched from the sources above with AI assistance, then checked against them before publishing.
