Subscribe
Share
Share
Embed
Power BI workspace apps promise a clean publish boundary between builders and consumers. But the mechanism that makes that boundary work — the copy, the separate IDs, the audience arithmetic — carries five traps that all fail in silence.
Episode 32 • 2026-08-07 Duration: 9:10
Power BI workspace apps promise a clean publish boundary between builders and consumers. But the mechanism that makes that boundary work — the copy, the separate IDs, the audience arithmetic — carries five traps that all fail in silence.
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.
When Publish Succeeds and Nothing Changes
Episode 32 | 2026-08-07
Fabric Architecture Podcast | Hosted by Matthias Falland with AI co-host Fabia
---
[00:08] Fabia: You add the report to the app. You hit publish. Your consumers see nothing.
[00:13] Matthias: No error?
[00:14] Fabia: No error. The publish succeeds. The report's sitting right there in the content list. Your consumers just... can't see it.
[00:22] Matthias: So you have to go in and manually flip visibility?
[00:25] Fabia: Every audience group, every time you add content. And that's one of at least five things about Power BI workspace apps that fail without telling you. Today we're pulling apart the publish boundary — the line between where your team builds and where consumers read — because almost everything that goes wrong here goes wrong in silence.
[00:47] Fabia: When you publish a workspace app, you create a copy. Every item that goes into the app is versioned separately, with its own unique ID — distinct from the workspace original. That copy is what consumers interact with.
[01:02] Matthias: Why a copy, though? Why not just a permission layer on the workspace?
[01:06] Fabia: Because the workspace is where work happens. You've got a report page mid-redesign sitting right next to the finished version your CFO needs Monday morning. Give a consumer workspace access and you've handed them both. The app splits that: one surface for building, one for consuming. And because it's a copy, every item in the app carries a new ID. Your audit log and your usage dashboard see two different objects and don't know they're related.
[01:36] Matthias: I'm on board with the stability model — you absolutely don't want a report changing while someone's presenting to their board. But the cost of two objects that nobody maps together? That's where I keep watching teams burn hours. They build a usage dashboard, the numbers don't add up, and nobody thinks to ask whether the app item and the workspace item are actually different objects. There's real maintenance hiding in that gap, and it's invisible until someone opens an audit trail.
[02:09] Fabia: The copy model opens a second gap that's harder to spot. Deployment pipelines — the mechanism you'd use to promote content from dev to test to production — they move items between workspaces. But the app isn't an item in the workspace. It's a property of it. So the pipeline moves your reports, your semantic models — and the app stays exactly where it was.
[02:32] Matthias: Wait — the pipeline succeeds and the app doesn't update?
[02:36] Fabia: The pipeline succeeds. The items land. Your consumers see nothing new until someone opens the app and hits Update. Microsoft's own documentation recommends creating a separate app per pipeline stage and updating each one by hand.
[02:51] Matthias: So your CI/CD ends at the publish button.
[02:54] Fabia: With a one-minute timeout on the update itself. If your app grows large enough, the update starts failing — and one of the documented remedies is recreating the whole thing as an org app. That's Microsoft telling you the successor exists.
[03:10] Matthias: What I keep running into is teams that automate their whole deployment pipeline and then discover the last mile — the part the consumer actually touches — is still a manual button click. That's the kind of surprise that makes people question everything upstream of it.
[03:28] Fabia: This one's from the Fabric Community forums. 'App audiences not inheriting permissions for upstream semantic models.'
[03:37] Matthias: Yeah — that's the one that catches people after everything else already looks right.
[03:43] Fabia: Picture it. A report sits on a chained semantic model — DirectQuery to another Power BI model, or to Analysis Services. You add the user to an audience. They can open the report. But the upstream model — the one the report actually depends on — lives in a different workspace. App permissions flow downstream. Never upstream. So the report renders partially or fails, and nobody gets a message saying you need access to the upstream model.
[04:12] Matthias: And the fix isn't in the app. You go to the upstream semantic model and grant access there — through an Entra security group, ideally, because doing it per user doesn't survive contact with a real model lineage. The app was never designed to reach that far.
[04:29] Fabia: Which means your permission model is a lineage exercise whether you planned for it or not. And if you don't know where your models chain, you don't know who's broken.
[04:40] Fabia: There's a limit most people read once and then forget. Ten thousand. That's the maximum combined users and user groups across the entire app.
[04:50] Matthias: That's not a number I'd expect anyone to hit.
[04:53] Fabia: Until you learn how the counting works. Workspace users — the people who build content — are counted once per audience group. Microsoft's own example: four workspace users, five audience groups, that's twenty entries consumed from the ten thousand before you've added a single consumer.
[05:12] Matthias: So the real cap is ten thousand minus your workspace membership times your audience count. And if you've been adding named users instead of security groups —
[05:22] Fabia: — each named user is one entry. A security group with a thousand people in it is also one entry. And when you cross the cap, it doesn't degrade. It blocks publish and update entirely. You're locked out of your own app.
[05:37] Matthias: That's the one I'd write on a Post-it for every team I work with. Security groups. One group is one entry regardless of size. A thousand named users are a thousand entries. The difference between those two is whether your app publishes or stops dead on a Tuesday morning when someone tries to add the eleventh audience.
[05:58] Fabia: The licensing question sits right under all of this. Publishing an app requires a Pro licence and the Member role. Consuming one requires Pro or Premium Per User — unless the workspace sits on an F64 or larger capacity. At F64, a Free licence with the Viewer role is enough.
[06:17] Matthias: That's the hinge. Below F64, distribution cost scales with headcount — every reader needs a per-user licence. At F64 and above, capacity replaces per-reader cost. Any conversation about whether to publish an app that doesn't start with the capacity SKU is arguing about the wrong variable.
[06:36] Fabia: And here's where the honest push-back lands on everything we've said. If the publish gate isn't what you need — if you want more than one app per workspace, or your content includes notebooks or real-time dashboards — workspace apps can't carry that. Org apps trade the gate for immediacy. Save is live, and you can have as many apps per workspace as you need. Paginated report model access is granted automatically, where workspace apps make you do it yourself.
[07:07] Matthias: Which is exactly right for teams where speed matters more than ceremony. Operational dashboards that need to reflect the last hour? A publish step just slows them down. I'd pick the org app there and own the trade.
[07:21] Matthias: The thing I'd take from today is that this system was designed to succeed without confirming the outcome. Your publish goes through. Your pipeline completes. And the question nobody thinks to ask is whether the consumer actually saw anything change. That gap between the action and the outcome — that's where teams spend their Tuesday mornings.
[07:44] Fabia: Pattern dictates platform. And this platform's pattern is silence. Somewhere right now, a team published their app, added three reports, and is waiting for users to call about them. The call's never coming. The reports are there, invisible, and nothing is going to say a word.
[08:03] Matthias: If that sounds like your Tuesday — DM me on LinkedIn. Find me as Matthias Falland.
[08:08] Fabia: Next week, org apps. The successor that trades the gate for speed.
[08:13] Matthias: The other tradeoff.
---
End of episode. ~08:14 estimated.