Subscribe
Share
Share
Embed
Org apps solved the decade-old broken-visual problem by managing permissions along the dependency chain. But the same engine that grants access on your behalf can leave records behind that you no longer have the rights to remove, and a single audience toggle can blow open an entire app.
Episode 33 • 2026-08-14 Duration: 9:45
Org apps solved the decade-old broken-visual problem by managing permissions along the dependency chain. But the same engine that grants access on your behalf can leave records behind that you no longer have the rights to remove, and a single audience toggle can blow open an entire app.
AI-generated voices. Matthias — cloned voice. Fabia — designed AI co-host. See Matthias live on YouTube (Fabric Friday), at his meetups, and at conferences like FabCon.
Hosted by Matthias Falland — Microsoft Data Platform MVP and community architect behind the Fabric Periodic Table. New episodes every Friday.
Have an architecture decision you are wrestling with? DM Matthias on LinkedIn — find him as Matthias Falland. Three to five sentences about the decision, your team size, and your current stack. We anonymize before airing.
This podcast was generated by AI. Both voices are synthetic: Matthias is a cloned voice, Fabia is a designed AI co-host.
Brand design based on fabricperiodictable.com.
Architecture decisions for Microsoft Fabric. Anonymized real customer scenarios, cost realism, counter-arguments included. Weekly episodes aligned with Fabric Friday recordings.
The Permission Broker That Outlives You
Episode 33 | 2026-08-14
Fabric Architecture Podcast | Hosted by Matthias Falland with AI co-host Fabia
---
[00:08] Fabia: No publish button. You save an org app, and it's live.
[00:11] Matthias: No staging? No review between the author and every consumer in the org?
[00:16] Fabia: None. And every save touches permissions across workspaces you may not be looking at.
[00:22] Matthias: So what happens when the person who set that up leaves the team?
[00:26] Fabia: Org apps are Fabric's answer to distributing content to consumers — reports, notebooks, dashboards. The headline feature is that they handle permissions along the dependency chain automatically. Today we're going through how that permission engine actually works, where it stops, and what it can leave behind.
[00:47] Fabia: The problem org apps solve goes back years. With workspace apps, you'd publish, the report would appear, and then a consumer would open it and see a broken visual. Because the app distributed a copy of the report, but the semantic model underneath — maybe in a different workspace entirely — was the author's problem. You had to remember to grant access to it separately, every time, for every consumer.
[01:14] Matthias: That spreadsheet is real. I've seen it in too many places to count.
[01:18] Fabia: The org app replaces that with a declared dependency graph. You add a report, Fabric traces it to its semantic model — same workspace or different — and grants the consumer read access automatically. Remove the user, and only the org-app-derived grant disappears. Access from a workspace role or a direct share survives.
[01:40] Matthias: Hold on — it reaches into a workspace the consumer has no role in? Across the boundary?
[01:45] Fabia: Yes. Because the relationship between a report and its semantic model is a first-class declared dependency. Fabric can see it, follow it, and manage access along it. Paginated reports get the same treatment — their model access is propagated automatically, which workspace apps never did.
[02:05] Matthias: That dependency tracking is the single most-requested improvement I keep hearing about in this space. Teams that've been managing Power BI distribution for years know exactly how much manual work it was. But I've also learned to ask where the automation stops, because that's where the next surprise lives.
[02:26] Fabia: And it stops at precisely the edges Fabric can't trace as declared dependencies. A lakehouse behind a Direct Lake model — that's a data-plane grant with its own security model, untouched. A paginated report referenced inside another report through an RDL visual — Fabric can't see that reference because it's buried in report definition content. The visual breaks silently for the consumer, and the author has no signal it happened.
[02:54] Matthias: So 'the app handles permissions' deserves a very specific footnote.
[02:59] Fabia: We got a question from the Fabric community. Org App doesn't grant semantic model access although the report is in the app. The report renders inside the app. The user cannot use the semantic model for anything of their own.
[03:15] Matthias: This is the line everyone trips over. The org app propagates read on the underlying semantic model — enough to render the report, which is what propagation is for. But Build is what lets someone connect from Excel or author a new report against that model. Build is never propagated by an org app. A workspace app can grant it, through a per-audience advanced setting, but only for models in the same workspace. An org app has no such switch — you grant Build on the model itself, as a deliberate decision about who gets to create with your data.
[03:51] Fabia: Propagation gets the picture on the screen. It doesn't make the model yours to build on. The person who filed that question read 'grants semantic model access' and expected the full set. The documentation means read. It should say that louder.
[04:07] Matthias: Let's talk about audiences. They're the other half of the org app — different views for different groups. That should be the security boundary, right?
[04:17] Fabia: It looks like one. Each audience is a child item in the workspace with its own permissions and share dialog. You can grant someone access to exactly one audience without ever opening the app in edit mode. But there's a setting per audience called Access to hidden content. And Microsoft's own description of its blast radius — if this setting is turned on for even one audience, users who have access to at least one audience can access all items included in the org app.
[04:49] Matthias: One audience. One toggle. Whole app.
[04:52] Fabia: Whole app. It exists for when audiences are navigation convenience, not security. But anyone flipping it while thinking 'just for this group' has misread it. Now — reaching back to your opening question. You can have the required permissions on a cross-workspace semantic model when you add a report to the org app, and later lose those permissions. The access records you created on that model stay. You can't revoke them. You need the semantic model owner to clear 'Access via related items' manually.
[05:26] Matthias: So the permission broker outlives the person who configured it. The delegation survives the delegator.
[05:33] Fabia: The licensing cliff is sharper than people expect. Org apps require Pro, a Fabric trial, or capacity. On an F64 or above, consumers with a free Power BI licence can view org app content — the capacity absorbs the per-user cost. Below F64, every consumer needs Pro. At Pro licence rates, a hundred consumers can easily reach four figures a month in licensing — just to look at the reports. The org app itself costs nothing. The audience it serves costs everything.
[06:04] Matthias: And this is where I'd push back on the 'always migrate' advice. Dashboards and scorecards aren't eligible item types — that's a hard wall for a lot of estates. And if you rely on the publish gate as a control point, the org app doesn't have one. Save is live. No staging, no review step. The workspace app isn't legacy in every case. Sometimes it's the only thing that works.
[06:29] Fabia: For teams that do move, the Git story is the strongest argument. Org apps have a real Git representation — definition version 2.0.0 with audience artifacts as children. Workspace apps have never had that. On the lifecycle axis, the successor is genuinely better, with one limit worth knowing before you build a pipeline around it. Org apps can't be deployed across stages using a service principal, and a service principal is what most automated pipelines run as. But give your app editors the Member role. Contributor can create an org app, and that's where its power stops. Every access change requires write and reshare on the included items and their underlying dependencies. There's even a workspace setting called 'allow contributors to update the app' that sounds like it should help — it applies to workspace apps only.
[07:25] Matthias: And one more to flag — the kind of thing that surfaces the morning of a demo. The documentation contradicts itself on whether org apps work in the Power BI personal app for Teams. One page says yes, another says no, both current as of this month. Verify it in your tenant. And if you can't verify it, say that. Thirty seconds of honesty builds more trust than a confident guess that turns out wrong in front of a stakeholder.
[07:54] Fabia: Pattern dictates platform. If your consumers need curated views of live workspace content, and you don't need dashboards, scorecards, or a publish gate — the org app is genuinely better at that job than workspace apps have ever been. The question is whether you've mapped the edges and the drift.
[08:13] Matthias: The thing I'd carry out of this episode is simpler than the feature list. Delegation has a cost that outlives the decision. You granted access through the app. You lost reshare. You moved on. The records are still sitting in 'Access via related items' on a model in a workspace you haven't opened in months. Nothing in the platform surfaces that for you.
[08:37] Fabia: Somewhere right now, there's a semantic model with an access record that was created by an org app edit, by someone who no longer has the authority to undo it. It's doing exactly what it was told to do. And nobody's watching.
[08:53] Matthias: If that made you check a workspace you haven't opened in a while — good. DM me on LinkedIn, find me as Matthias Falland.
[09:01] Fabia: Until next Friday.
---
End of episode. ~09:02 estimated.