At FabCon Atlanta on March 18, 2026, Microsoft launched Planning in Microsoft Fabric IQ as a first-party capability, co-engineered with Lumel. “First-party” is a label Microsoft uses sparingly, and it carries meaningful consequences for how Fabric Planning is bought, governed, and integrated with the data platform you already run. To understand what that means for your organization, it helps to start with how Microsoft uses the term, and then look at the impact it can bring to the various teams in your enterprise (in addition to the core business teams that use Fabric Planning).
First-party means the capability belongs to Microsoft. It is not an ISV application bolted onto the platform through connectors and APIs, and it is not a marketplace transaction that Microsoft merely facilitates. Microsoft is the vendor of record. Fabric Planning is sold by the Microsoft account team, billed as consumption units on Fabric capacity, and supported through the same escalation channels as every other Fabric workload.
That sits in contrast to an ISV published on AppSource or the Azure Marketplace, where Microsoft plays only a channel marketplace role while the vendor owns and deals with the product, relationship, procurement, security assurance and the renewal hassle. Both models are legitimate; they answer different questions. Marketplace lowers the friction of buying something third-party. First-party removes the third party altogether.
Thousands of ISVs move through AppSource and the Azure Marketplace. The set Microsoft treats as first-party is much smaller, and the pattern has been consistent for nearly a decade: when a new platform wave needs a capability Microsoft does not want to build entirely in-house, it picks a specialist partner and co-engineers the capability into the stack rather than bolting it on.
A few examples:
Microsoft applied the first-party label to Fabric Planning at the March 18 launch, placing enterprise planning in the same small cohort of capabilities it has used to anchor each new platform wave: data engineering, AI, and now enterprise planning inside Fabric. What the change means in practice depends on which team in your organization is asked.
Fabric Planning is available as part of Fabric capacity that you already run, billed through your existing Microsoft agreement, and the spend counts toward your MACC. You need not onboard a new vendor, enter into a new Master Services Agreement, or initiate a procurement workstream to start using Fabric Planning.
Licensing is activity-based by user persona, and not on a named-user basis. You pay for user activity each session (730 hours, roughly 30 days), only if the user uses it. This fits the cyclical nature of planning, where usage is concentrated around budget, forecast, and close cycles, and is minimal in between. It frees you from annual or multi-year contractual commitments for seasonal or occasional users, reviewers, and approvers.
Since plans and budgets are not managed in a siloed planning platform, there is no need to manage a separate planning identity. Plans live inside your Fabric tenant, with identity flowing from Entra ID. The same accounts, groups, and conditional access policies that govern the rest of your Fabric workspace also govern who can access a plan. Row-level security carries through from your Power BI semantic model, which means the rules your team has already written and tested are the rules that determine who can see which numbers inside a plan.
When someone leaves the organization and their Entra ID account is disabled, their access to plans goes with it automatically, with no separate identity to deprovision and no admin console where stale accounts have to be cleaned up after the fact. The security review work you completed when you adopted Fabric, including your threat model, data residency posture, and audit trail design, applies to planning as well and does not need to be repeated.
Plans and actuals share one governed data estate inside Fabric, so there is no pipeline to maintain between them and no separate warehouse where plan data lives apart from your actuals. Variance measures read from a single source, which means the variance shown in Power BI and the variance shown inside the planning capability are calculated from the same underlying data and stay reconciled by default.
This is the opposite of the usual pattern where data lives in the warehouse and plans live in a siloed planning platform, with a pipeline maintained between them. Over time the numbers drift, and reconciliation becomes recurring engineering work that has to be repeated each cycle.
For data that lives outside Fabric, including Snowflake, Databricks, BigQuery, SAP, and Oracle, OneLake mirroring and shortcuts pull it in without standing up an ETL pipeline, so plans can sit alongside actuals from any of those sources without duplicating the data.
Planning adds a business intent layer on top of Fabric IQ’s semantic foundation, which means agents reasoning over your data can now reach not just descriptions of what has happened in the business, but the goals, targets, constraints, and trade-offs that define what was supposed to happen. Agents access Fabric IQ through a Microsoft-provided MCP server (currently in preview), and with Planning in place, they can read across three time horizons from a single source: what has happened, what is happening now, and what is supposed to happen.
Without that intent layer, an agent answering “are we on track?” can describe the past accurately but has no way to compare it against the plan, because the plan is not part of the model the agent is reasoning over. With Planning available as a Fabric capability, that comparison becomes part of the agent’s reach by default rather than something each team has to wire in separately.
Support for Fabric Planning runs through Microsoft on the same escalation path you already use for Fabric capacity. No separate support contract is needed to set up alongside your Fabric agreement. The processes your IT organization has already established for Fabric incidents extend to planning workloads without modification.
A reasonable question about any first-party capability is whether the engineering underneath is production-grade or a 1.0 bet. Fabric Planning is not a greenfield build. Its core engines have been shipping in production for years through Lumel’s heritage product line, voted the Best Overall EPM Vendor of 2025 by BPM Partners. Co-engineering a proven engine into Fabric is more credible than rebuilding the category from scratch, and it shortens the path from preview to enterprise-grade deployment.
The first-party launch enhances the planning capability itself as it integrates seamlessly with native Fabric experiences. But more than that, what changes is the architecture around it, including how it is bought, where the data sits, who owns the security boundary, how AI reaches it, and who handles support. That change is what each of the teams above can begin to feel from day one.
For anyone planning on the Microsoft stack over the next two or three years, planning no longer needs to be a separate tool to integrate with your data platform. It is now a capability within your data platform. If an agent-era operating model is on your roadmap, the business intent layer now sits in the same environment where your governed data and agents already run. That is what “first-party” actually means in practice: not a label on a partnership, but a shift in where planning belongs inside your stack.
Your Microsoft account team can walk you through what that looks like for your environment on your existing contract, and we are happy to join that conversation.
Discover how PowerTable on Microsoft Fabric enables governed self-service apps for onboarding, approvals, requests, and tracking.
