Microsoft Fabric has changed how organizations think about their data platform. By unifying data engineering, analytics, governance, and AI workloads under one roof, it has eliminated much of the architectural sprawl that plagued earlier approaches.
But there’s a quieter revolution happening alongside the platform itself: the ISV workload model. And for finance and planning teams, it may be the most consequential development in enterprise software architecture in years.
If you manage a Fabric environment—or if you’re evaluating how to modernize your planning stack—understanding what native ISV workloads mean in practice is worth your time. The implications for security, cost, and user experience are significant.
The Old Model: SaaS as a Separate Island
For the past two decades, enterprise planning tools have followed a consistent pattern. You subscribe to a cloud-based SaaS platform. Your data gets replicated from your systems of record into that platform’s proprietary data store. Your users log in with a separate identity. Your IT team manages a separate set of roles, permissions, and security policies. And when it’s time to report, you extract data back out.
This model works—in the sense that organizations have used it for years. But it creates a specific set of structural costs:
- Data duplication. Your actuals exist in your data platform and in the planning tool’s cloud. These copies drift, and reconciliation becomes an ongoing operational tax.
- Security fragmentation. You’re maintaining two identity systems, two access control models, and two audit trails. If your organization has invested in Microsoft Entra ID, row-level security in your semantic models, and workspace governance in Fabric, none of that is inherited by a standalone planning tool. You’re rebuilding it from scratch.
- ETL overhead. Moving data between your platform and the planning tool requires pipelines that need to be built, maintained, monitored, and debugged. These integrations are a persistent source of friction—and a point of failure.
- Per-user licensing costs. Most legacy EPM tools charge per named user, with expensive annual contracts. This creates a perverse incentive to restrict access—exactly the opposite of what modern self-service analytics is trying to achieve.
For years, these costs were accepted as the price of doing business. But the ISV workload model in Fabric offers a fundamentally different approach.
The New Model: ISV Workloads as Native Extensions of Fabric
Microsoft introduced the ISV workload framework to allow third-party applications to run inside Fabric—not alongside it, not connected to it, but actually embedded within the platform itself.
Here’s what that means in practice:
- The ISV application appears as a workload within your Fabric workspace. It’s not a separate URL, a separate login, or a separate environment. It’s part of the same workspace where your lakehouses, warehouses, semantic models, and reports already live.
- Data stays in OneLake. The ISV workload reads from and writes to the same data store as everything else in Fabric. There’s no proprietary data silo and no replication required. Your data never leaves your tenant.
- Security is inherited, not rebuilt. The workload respects your existing Fabric workspace roles, Microsoft Entra ID security groups, and row-level security policies. If a user has Viewer access in the workspace, they have Viewer access in the ISV workload. There’s no separate user management to maintain.
- Capacity is shared. The workload runs on your Fabric capacity, measured in the same Capacity Units (CUs) you already manage. This enables consumption-based pricing instead of per-user licensing—a fundamental shift in the economics of enterprise planning software.
In short, a native ISV workload is not a bolt-on. It’s a first-class citizen of your Fabric environment.
Side by Side: Standalone SaaS vs. Native ISV Workload
| Dimension | Standalone SaaS EPM | Native ISV Workload |
|---|---|---|
| Data residency | Vendor’s cloud / proprietary store | Your OneLake tenant |
| Identity & access | Separate user management | Inherited from Entra ID & Fabric roles |
| Row-level security | Rebuilt in vendor’s system | Inherited from semantic model |
| Data movement | ETL pipelines required | None — reads/writes directly |
| Pricing model | Named-user annual licenses | Consumption-based (Fabric CUs) |
| Governance & audit | Separate audit trail | Unified with Fabric governance |
| User experience | Separate app with separate login | Embedded in Fabric workspace |
What This Means for Finance Teams
For Fabric administrators and architects, the implications of the ISV workload model are architectural. But for finance and planning teams—the people who actually build budgets, run forecasts, and present to the board—the implications are deeply practical.
Faster time to value. Because a native workload operates on your existing data and semantic models, the implementation doesn’t begin with a months-long data migration project. You connect to the semantic model you already have. Your planning application can be up and running in hours, not months.
Broader access without broader cost. Consumption-based pricing eliminates the tension between “we need more people in the planning process” and “we can’t afford more licenses.” Seasonal budget contributors, occasional scenario reviewers, and ad-hoc users can participate without driving up your annual spend.
Trust in the numbers. When plans and actuals share the same definitions, the same security, and the same data store, the question “Why does my report show a different number than the budget?” disappears. Not because you’ve fixed a bug, but because the architecture makes that inconsistency impossible.
No IT overhead for separate governance. Finance teams won’t need to file IT tickets to add users to the planning tool, manage separate role assignments, or maintain integration pipelines. The planning application inherits everything from the Fabric environment that IT already manages.
How Lumel EPM Delivers on the Native Workload Promise
Lumel EPM is the first and only enterprise planning solution built as a native ISV workload in Microsoft Fabric. As a Microsoft Strategic ISV Partner for Fabric, Lumel didn’t retrofit an existing SaaS product to connect to Fabric—it was architected from the ground up to operate inside it.
This means:
- Planning applications are built directly on your semantic models. The business logic you’ve already encoded—dimensions, hierarchies, measures—is reused, not rebuilt. There’s no parallel modeling exercise.
- All data reads and writes go directly to OneLake. Budgets, forecasts, and scenarios are stored in the same governed data store as your actuals. No proprietary database. No replication.
- Your Fabric security model applies automatically. Workspace roles, Entra ID groups, and row-level security are inherited—not reconfigured. There’s no separate user management layer.
- Consumption is measured in Fabric Capacity Units. No named-user licenses, no annual contracts. Usage-based pricing means you pay for what you use and can open participation to seasonal, occasional, and ad-hoc budget contributors without cost anxiety.
- Business users can build planning applications without IT. Lumel’s no-code, self-service interface means finance and planning teams can create and modify workflows—budgeting, scenario modeling, driver-based planning—independently, within the familiar Fabric workspace.
This isn’t a vision of what native planning could look like someday. It’s what Lumel EPM delivers today—trusted by thousands of enterprises worldwide.
Why This Matters Even If You’re Early in Your Fabric Journey
You don’t need a fully mature Fabric deployment to benefit from this architectural shift. If you’re using Fabric today—or even just starting to explore it—understanding the ISV workload model helps you make better decisions about your planning stack now.
Choosing a planning tool that operates natively in Fabric means you’re not creating a new silo that you’ll have to migrate away from later. You’re investing in an architecture that grows with your platform adoption. Your planning data will already be in OneLake when you’re ready to build AI workloads on top of it. Your security model will already be unified when your governance requirements tighten.
In other words, the ISV workload model isn’t just about how applications run inside Fabric today. It’s about the decisions you make now that determine how easily your environment scales tomorrow.
The Bottom Line
The ISV workload model represents a genuine architectural innovation—one that changes the economics, security, and user experience of extending Fabric for enterprise use cases like planning.
For finance teams, it means planning can finally live where the data already does—governed by the same policies, accessible to the same users, and visible to the same AI workloads. No separate cloud. No separate licenses. No separate truth.
The era of planning as a disconnected SaaS island is ending. The platform era has arrived.
