Is Microsoft really turning Power BI dashboards into real applications now? → Yes: Microsoft is bundling Fabric Apps and Fabric Database capabilities for Power BI Pro and Premium Per User customers, signaling that dashboards and apps are converging inside Fabric.
What is the engineering decision we actually have to make this quarter? → Whether to let business teams start building stateful, write-back ‘data apps’ in Fabric via Power BI licensing, and how to control the hand-off to developers and IT.
What is the dominant risk? → Not the LLM coding agents or the SDK itself; it’s the governance gap between ‘someone built it’ and ‘we can operate it’ once shared state, authentication, and databases enter the picture.
What’s the core technical shift behind the news? → Microsoft is using Power BI’s massive installed base (425,000 organizations and more than 35 million monthly business users) as a distribution channel for Fabric’s higher-end database and app-building stack.
What’s the angle we take at Plavno? → Treat Fabric-in-Power-BI as a controlled promotion pipeline: prototype in the business layer, then promote to an IT-owned operating model with explicit security, data, and release gates.
Quick Answer: should we enable Fabric Apps and Fabric Database for Power BI users?
Yes, but only if we treat it as a governed path from prototype to production rather than ‘self-serve app development.’ Microsoft is deliberately collapsing the boundary between dashboards and apps by bundling Fabric Apps and a Fabric SQL database (up to 1GB per app) into Power BI Pro and Premium Per User, and your architecture has to assume these artifacts will become operational systems that write back data, preserve shared state, and require real ownership.
If you allow business-built apps to persist shared state and write back data, you have created production software whether you call it a dashboard or not, and the right response is to design an explicit hand-off and control plane before the first ‘helpful’ app becomes business-critical.
The dominant signal: Microsoft is using Power BI to distribute Fabric, not the other way around
Microsoft is pushing Fabric to a new set of commercial users ‘an order of magnitude’ larger than its current base by targeting Power BI’s footprint: Power BI has more than 425,000 customers worldwide, while Microsoft cites 40,000 Fabric customers today and more than 35 million monthly business users in Power BI. The practical meaning for engineering leaders is that Fabric is no longer a separate platform choice made only by data engineering teams; it is being pulled in through BI licensing decisions.
- Licensing becomes architecture: when Fabric Apps and Fabric Database arrive ‘at no additional cost’ for certain Power BI licenses, orgs will adopt a database and app runtime implicitly.
- State enters the BI layer: once apps accept inputs, write back data, and preserve shared state, you’ve moved from read-only analytics to operational workflows.
- The hand-off is the product: Microsoft explicitly says apps can be expanded and handed off to developers and IT teams without rebuilding; your process has to make that true.
- Agents amplify throughput, not quality: Rayfin is designed to work with GitHub Copilot, Claude Code, Codex, or other coding agents, which increases output and therefore increases review and governance load.
Central claim: the failure point will be the promotion boundary between business-built Fabric apps and IT-owned systems
Microsoft’s move is not primarily about an SDK or a new database feature; it’s about creating a continuous path from a Power BI artifact to a Fabric application that can carry authentication, security, and a SQL database. That breaks a common engineering practice: treating BI as an endpoint with lighter governance than operational systems. The right response is to design a promotion boundary early, where an app transitions from ‘business-owned experimentation’ to ‘IT-owned production,’ with explicit controls for identity, data write-back, and operational ownership inside Fabric.
At Plavno, we’ve seen the same pattern whenever a tool that started as reporting gains state and workflow. The moment users can input data and the system can write back, the platform becomes part of your operational architecture. It doesn’t matter that the starting point is Power BI; you now have something that looks and behaves like an internal application, and it will be treated that way by the business when it becomes indispensable.
Why this quarter is different: Microsoft removed the ‘platform selection’ friction
The hidden architectural consequence: BI teams can now create databases by accident
Microsoft is explicitly bundling Fabric Apps and Fabric Database capabilities (up to 1GB per app) into Power BI Pro and Premium Per User. In practice, that means a Power BI expansion can implicitly create new data stores and operational workflows under the BI umbrella. Engineering leaders who assume they can defer Fabric decisions to ‘later’ are likely to find that Fabric artifacts already exist, and the only remaining decision is how to govern and operate them.
What Rayfin changes: dashboards can accept inputs, write data back, and preserve shared state
Microsoft describes Rayfin (an open source SDK) as a way for users to create their own data applications that accept inputs, write back data, preserve shared state, and support operational workflows across to Fabric. That is a qualitative shift from ‘visualization on top of a dataset’ to an app that actively mutates data and maintains application state. Once you do that, you have to reason about data correctness, authorization boundaries, and lifecycle management the way you would for any internal system.
The real architectural pivot: a 1GB Fabric SQL database per app turns BI into an app platform
Microsoft is attaching a Fabric SQL database, authentication, and security to each application built via Rayfin, with up to 1GB per app under the included capabilities. Even without debating whether 1GB is ‘enough,’ the engineering implication is that data ownership and data modeling decisions can now originate in the BI layer. When an app grows, Microsoft positions it to be expanded and handed off to developers and IT without rebuilding, which makes the hand-off contract the core technical artifact you need to define.
Prototype stage inside business teams: a small Fabric app is built to capture inputs, preserve state, and automate an operational workflow adjacent to analytics.
Adoption stage across a department: the app becomes relied upon, and changes start to require coordination, permissions work, and data quality discussions.
Promotion stage to IT ownership: the app must be migrated into a managed delivery process, with clear ownership of the database, identity model, and release cadence.
Integration stage with enterprise systems: write-back behavior begins to touch systems of record, turning the ‘BI app’ into operational infrastructure.
Agent-assisted building makes governance the bottleneck, not development capacity
Rayfin is designed to work with GitHub Copilot, Claude Code, Codex, or any coding agent, enabling users to instruct an agent to build an application and deploy it in a Fabric environment. This doesn’t magically make apps correct; it makes app creation cheap. Cheap creation shifts cost to review, security validation, and operational readiness. If you don’t build a governance funnel, agent-driven generation will simply multiply the number of artifacts that feel production-like but lack production discipline.
| Fabric-in-Power-BI capability (from Microsoft) | What it enables in practice | What engineers must decide |
|---|---|---|
| Fabric Apps bundled with Power BI Pro / Premium Per User | BI users can build ‘apps,’ not only dashboards | Define who can create apps and where they can deploy |
| Fabric Database per app (up to 1GB), with authentication and security | Apps can store state and write back data | Decide ownership of schemas, access, and lifecycle |
| Rayfin apps can be handed off to developers/IT without rebuilding | A prototype can become a system | Define promotion gates and operational standards |
| Designed to work with coding agents (Copilot, Claude Code, Codex) | Faster creation and iteration | Decide how review, testing norms, and approval scale |
Why ‘porting to Power BI’ is less important than the operational hand-off contract
Microsoft argues that apps built in Fabric can be ported to Power BI without much additional work or cost. Portability is helpful, but the bigger issue is whether the app’s data and identity assumptions are compatible with how your organization runs software. If an app preserves shared state and writes back data, the operational contract has to specify what ‘correctness’ means, who can change schemas, how access is granted and revoked, and what happens when an app becomes a dependency for a workflow.
In practice, the hard problems appear at the seams: where business teams build quickly, and IT teams inherit obligations. If you want the promise of ‘hand it off without rebuilding’ to hold, you need standards for how Fabric apps are structured and how they interact with data stores and permissions from day one.
Fabric’s bigger bet: one integrated analytics environment, now pulled into BI purchasing
Fabric was announced by Microsoft in 2023 as an integrated analytics, data warehouse, and data lake environment. Microsoft has since added data mirroring so users can run analytics on data in other environments without pushing SQL queries directly to them, and it added transactional databases including Cosmos DB and Fabric SQL. The shift this week is that Fabric’s app and database story is being distributed to Power BI customers, effectively turning BI licensing into a gateway for an integrated data platform.
- Integrated means shared blast radius: when analytics, warehouse, lake, and transactional components live under one banner, a misconfigured workflow can affect more than reporting.
- Mirroring changes ‘where queries run’ conversations: teams will ask for analytics on data elsewhere, and the architecture choice becomes part of governance.
- Transactional elements raise the stakes: once transactional databases are in the same environment, ‘read-only BI’ assumptions stop applying.
- Ecosystem integrations drive adoption: if CRM and other platforms feed context for analytics and AI, the path from insight to action shortens.
The Salesforce Data Cloud 360 preview is the tell: Fabric wants to be the context layer for AI and analytics
Microsoft says it is extending integration with other platforms, including Salesforce, and is previewing bidirectional integration with Salesforce Data Cloud 360. The stated goal is to make CRM data available across the Microsoft system for analytics and AI, including as business context for Fabric data agents, without duplicating that data. For architects, the key is that the ‘context layer’ for AI and analytics is shifting toward Fabric, even when systems of record stay elsewhere.
When Microsoft says ‘without duplicating data,’ the engineering work doesn’t disappear; it moves into identity, permissions, lineage, and deciding which system is allowed to write back when bidirectional integration exists.
Distinctions between a dashboard and an app are disappearing, so treat Power BI as an app surface
A Microsoft executive explicitly framed the move as the disappearance of distinctions between a dashboard and an app. That is the crux of the engineering change: Power BI is no longer just a consumption layer if it becomes the distribution point for app-building with state and write-back. The right mental model is to treat Power BI as an app surface that happens to be popular with business users, and to build policies accordingly rather than pretending it remains a reporting-only tool.
Decide what ‘app’ means internally: if an artifact writes back data or preserves shared state, treat it as software that needs an owner and a lifecycle.
Define the promotion boundary: specify what must be true before a business-built Fabric app becomes supported by IT.
Standardize identity and access assumptions: align app authentication and security with enterprise expectations before adoption spreads.
Plan for agent-assisted velocity: assume Copilot/Claude Code/Codex will increase the number of apps and require scalable review norms.
How we’d run this at Plavno: a two-lane operating model that keeps innovation without losing control
At Plavno, we would not try to stop business teams from experimenting with Fabric apps if the organization is already deep in Power BI. Instead, we’d formalize two lanes: an experimentation lane where teams can validate workflows quickly, and a production lane where IT assumes ownership, hardens security, and aligns the app with operational standards. The whole point is to make the ‘hand it off without rebuilding’ promise achievable by design.
This maps well to how many organizations already treat analytics prototypes versus production pipelines, but it needs to be explicit because Rayfin adds state and write-back. If we’re building or modernizing systems around this, we typically anchor the program under a broader digital transformation initiative so governance, ownership, and change management are built in rather than bolted on.
| Decision point | If you choose ‘yes’ | If you choose ‘no’ |
|---|---|---|
| Allow Fabric Apps creation via Power BI licensing | Faster workflow prototyping close to business users | Fewer new artifacts, but more pressure on IT to deliver apps directly |
| Permit write-back and shared state in early apps | Rapid operationalization of analytics | Keeps BI read-only, but may block legitimate workflow needs |
| Use external data (e.g., Salesforce Data Cloud 360 preview) as context | Cross-platform analytics and AI context without duplication (as described) | Simpler boundaries, but less integrated context for Fabric data agents |
| Embrace coding agents in the build process | Higher throughput; review becomes the bottleneck | Lower throughput; potentially fewer governance incidents |
The business impact is not ‘better dashboards,’ it’s faster operational workflows built by the people who own the process
When Power BI users can build apps that accept inputs, preserve state, and write back data, the organization gains a direct path from analytics to action. That can compress feedback loops: a sales operations team can move from seeing a metric to triggering a workflow inside the same environment. Microsoft is clearly betting that this will pull customers into Fabric’s higher-end database services and app-building tools using the distribution it already has.
The flip side is that operational workflows create new expectations. Once a workflow exists, it must stay up, must be secure, and must not corrupt data. If you let this emerge organically, you can end up with critical processes embedded in tools that were never staffed or governed like production systems.
How to evaluate Fabric Apps in practice: treat it like adopting a new internal app platform
The evaluation should not start with ‘can we build a nicer Power BI experience.’ It should start with whether you are willing to operate a new class of internal applications inside Fabric, often initiated by business users, and then promoted to IT. Because Microsoft is bundling these capabilities into existing Power BI licenses, adoption pressure will come from cost and convenience, not from a carefully designed architecture program.
A practical evaluation looks like an operating model exercise: where will apps live, who approves deployment, who owns the Fabric SQL database tied to each app, and how you will manage authentication and security across teams. The fact that Rayfin is scheduled for preview in the coming weeks is another reason to decide early: you want a policy ready before the first successful app becomes the template for the next dozen.
- Start from a real workflow, not a demo: pick a process that genuinely needs input capture or write-back, otherwise you’ll under-estimate governance needs.
- Assume the app will outgrow the creator: Microsoft explicitly frames expansion and hand-off to developers and IT; design for that future.
- Decide who owns the database: a Fabric SQL database per app is powerful, but it can fragment ownership if you don’t define it.
- Plan for cross-platform context early: if Salesforce data is involved, decide boundaries before bidirectional paths exist.
- Make ‘security’ a first-class acceptance criterion: authentication and security are part of the offered stack; require alignment, not exceptions.
Real-world patterns we expect: Power BI teams will create the first operational systems, then IT will inherit them
In real organizations, Power BI is often owned by analytics teams close to the business, while IT owns production applications. Microsoft’s bundle collapses that divide. The most common pattern we expect is that a Power BI team builds a Fabric app to solve an immediate problem, it succeeds, usage expands, and then the need for developer involvement appears. This is exactly what Microsoft is facilitating: apps can grow and be handed off without rebuilding.
At that point, the engineering question is not whether Fabric can do it; it’s whether your organization can absorb it. If your developers inherit a portfolio of stateful apps with unclear ownership and inconsistent data models, you’ll spend more time stabilizing than delivering. If you build a clear path from the beginning, the business gets speed and IT gets an operable artifact.
Your strongest control is not blocking creation; it is defining the moment an app becomes ‘supported,’ and requiring that supported apps meet a minimal operational contract that developers can actually maintain.
Where risks concentrate: write-back, shared state, and bidirectional data paths
The risks in this shift are predictable because they follow the nature of stateful systems. Write-back means changes to data must be correct and auditable according to your internal standards. Shared state means concurrency, permissions, and lifecycle matter, even if the tool hides complexity. Bidirectional integration, such as the Salesforce Data Cloud 360 preview described by Microsoft, implies that data can flow both ways, and that forces clarity about what system is authoritative for which fields and workflows.
These aren’t reasons to avoid Fabric Apps; they are reasons to decide deliberately. The organizations that get value will be the ones that acknowledge that ‘data apps’ are software systems and put them under a lifecycle that matches their impact.
What to watch as Rayfin enters preview: distribution beats capability
The engineering warning sign: a sudden spike in ‘small’ apps
Because Rayfin is designed to work with coding agents and is being distributed to a huge Power BI base, we should expect a surge of small internal apps. Many will be harmless prototypes. A few will become deeply embedded in operations. The engineering move is to instrument the social and technical lifecycle: where apps are deployed, who uses them, and which ones start to control business processes.
The moment an app starts preserving shared state for a group and writing back data that affects downstream decisions, it should be treated as a system of record adjunct and promoted into IT’s operating model. Without that trigger, you won’t notice the transition until an incident forces it.
The practical response: build a ‘promotion pipeline’ from Power BI experiments to IT-owned Fabric systems
The right way to respond is to accept the distribution reality and create a promotion pipeline that formalizes hand-off. That pipeline should reflect Microsoft’s own narrative: users build apps, apps grow, and then developers and IT take over without rebuilding. Your job is to make ‘without rebuilding’ mean ‘without replatforming or rewriting’ rather than ‘without understanding what we inherited.’
When organizations ask us to design this kind of lifecycle, we typically implement it as part of an enterprise AI and automation program, because the same pressure exists there: prototypes become operational faster than governance evolves. If you want a partner to shape the operating model and architecture around Fabric-style internal apps and agent-assisted development, that maps directly to our AI automation services work.
Author and freshness
Plavno team. Last updated: September 2026.
Chat GPT 
Perplexity 
Claude 
Gemini 
