How FabCon 2026 Changes How We Build Power BI Projects

Navy Solv Systems title card reading 'How We'll Build Power BI Projects' with a continuous loop motif.

In Short: How FabCon 2026 Changes the Way We Build Power BI Projects

Watching the FabCon Europe 2026 keynotes, the announcement that will change our day-to-day work most was not the loudest one. It was a line in the Power BI September 2026 feature summary: Power BI Projects (PBIP) are generally available, and PBIR is now the default report format for PBIX and PBIP files.

Put that next to the Git improvements, the remote Power BI Authoring MCP server in preview and a per-model switch for AI access, and the way we build Power BI projects at Solv. Systems changes from here on. Every new project now starts as a PBIP in Git, with an agent in the build loop and an AI access decision written into the plan. For the full list of what Microsoft announced, our FabCon Europe 2026 recap is the place to start.

PBIP Is Our Default Now, Not an Option

For years we treated PBIP as the "proper" way to work and PBIX as the practical one. That argument is over. With PBIR the default, a report's pages, visuals and bookmarks each sit in their own file, and the semantic model is stored as TMDL. Microsoft Learn says PBIR "greatly improves change tracking and merge conflict resolution". A pull request shows exactly what changed, and two developers on different pages stop treading on each other.

So every new Power BI project we deliver starts life as a PBIP, saved into a repository on day one. For existing estates, we treat the first edit as the migration moment, because editing a legacy report converts it to PBIR anyway, in Desktop and in the service, and in practice that conversion is one-way.

Two checks come before anyone edits a business-critical report:

Sensitivity labels - Learn says they "aren't supported with Power BI projects", which can decide which reports move first
Where the files live - you cannot save a PBIP directly to OneDrive or SharePoint, so the habit a lot of teams have of keeping reports in a Teams folder has to go

Our guide to PBIP and PBIR in Power BI has the full list of limitations and a migration checklist.

Git and CI/CD From Day One

The Git side of Fabric moved too. Compare and commit, selective branching and the bulk import and export APIs are now generally available. Deployment plans and file-level commits are in preview, as is delegated administration for branch workspaces, which lets developers create branch workspaces inside guardrails an administrator sets.

My view is that this removes the last excuse for "we'll add CI/CD in phase two". Phase two rarely comes. So our project plans now include, in week one:

A repository and branching model agreed with the client's team, because they own it after we leave
A pull request rule for every change, with a named approver for model changes and another for report changes
A deployment route through Fabric Git integration or the APIs, which deploy metadata only, rather than publishing from Desktop, which uploads a temporary PBIX with the local data cache

We'll keep the preview items out of client production pipelines until they are generally available. Our guide to Git integration and CI/CD in Microsoft Fabric covers the mechanics.

One cost thought. Development and branch workspaces sit idle most of the day, which is exactly the shape F0 and on-demand billing are aimed at. Both are coming soon and Microsoft hasn't published pricing, so we're not building plans around them yet. Our F0 and on-demand billing explainer sets out what is known, and our pilot-first, reserve-later playbook covers how we'll test it once it lands.

Agents in the Build Loop, With a Person Holding the Pen

The local Power BI Authoring MCP server - the one we covered as the Power BI Modeling MCP server - remains generally available and works against Power BI Desktop, PBIP and TMDL files on disk. The new remote version is in preview: it creates and modifies semantic models in Fabric workspaces with nothing installed locally, so it also works on a Mac. It needs a Fabric tenant setting turned on, and Microsoft advises against registering the local and remote servers at the same time.

How we use agents on projects now:

Mechanical work goes to the agent - naming conventions, descriptions on every measure, display folders, format strings, model documentation
Business logic stays with a person - complex DAX can look right, run without error and still be wrong, so a developer writes it or checks it line by line
Everything goes through Git - because the project is PBIP, every agent change lands as a diff that someone reviews and can revert
Approval prompts stay on - the local server asks for approval before its first change and first query, and we don't switch that off on client work

That loop is usually GitHub Copilot in VS Code, talking to the authoring server. Power BI Desktop Bridge, in preview, lets an agent reload its changes in a running copy of Desktop and take screenshots to check its own work. Useful, but a convenience, not a control. The control is the pull request.

What PBIP really changes is that agents and people now edit the same text files under the same review rules. That's what makes agents safe enough for client work.

Fabric Apps Change the Scoping Conversation

Microsoft says apps in Power BI will be available in preview to Power BI Pro and Premium Per User customers, as well as Fabric capacity customers, with Fabric Database capabilities up to 1 GB per app at no additional cost. The posts say "in the coming weeks" for the preview and "in the coming months" for the Power BI Desktop experience, so it isn't something we can deliver yet.

What changes now is scoping. In requirements sessions we've added a question: does anyone need to act on these numbers, not just read them? Budget inputs, corrections and sign-offs are the obvious candidates. When the answer is yes, we design the semantic model with that in mind, knowing that write-back lands in a SQL database in Fabric rather than in the model itself, and that sharing an app can grant access to the items it depends on. Our post on pay-per-use Fabric for small teams covers what this means for organisations running on Power BI Pro alone.

AI Access Is Now a Delivery Decision

Fabric IQ in Microsoft Copilot Chat and Cowork is generally available, and so is the Fabric IQ MCP server. Every semantic model we hand over is now potentially an AI surface for Microsoft 365 users.

The control that matters most sits on the model. A per-model setting decides whether read-only users can reach it through Power BI Copilot, Microsoft 365 Copilot Chat and Cowork, data agents and the remote Fabric and Power BI MCP servers. It is on by default, and it is not inherited by models built on top of another model.

So AI access is now a line in our handover checklist, next to row-level security and endorsement. For each model we agree with the owner whether it is ready to be answered from, write the names and descriptions that make the answers good, test row-level security as a viewer, and turn the setting off where the model isn't ready. Our guide to Microsoft 365 Copilot in Power BI covers how the administrator and model-level controls fit together.

Where Solv. Systems Comes In

This is about Power BI projects a client's team can still maintain, review and trust a year after we've left. If you want your next one built that way - PBIP in Git, agents doing the mechanical work, AI access decided model by model - our Power BI consulting team is happy to talk it through. For my wider view of the week, see my takeaways from FabCon Europe 2026.

Sources and Further Reading

Frequently asked

Because the default storage is now source-control friendly. With PBIP generally available and PBIR the default report format for PBIX and PBIP files, report pages, visuals and bookmarks sit in separate files and the semantic model is stored as TMDL. Changes can be reviewed as diffs in a pull request, so Git stops being an optional extra and becomes the normal way to work.

Not immediately. Legacy reports still open as they are, but editing and saving one converts it to PBIR, in Power BI Desktop and in the service, and in practice the conversion is one-way. We treat the first edit as the migration moment and check for sensitivity labels first, because Microsoft Learn says they are not supported with Power BI projects.

Compare and commit, selective branching and the bulk import and export item definition APIs are generally available. Deployment plans, file-level commits and delegated administration for branch workspaces are in preview. We keep the preview items out of client production pipelines until they reach general availability.

For mechanical work, yes: naming conventions, descriptions, display folders, format strings and documentation. For business logic, a developer writes or checks every line, because complex DAX can run without error and still return wrong results. Working in PBIP under Git means every agent change is a diff someone reviews and can revert.

The local server is generally available and works against Power BI Desktop, PBIP and TMDL files on disk. The remote server is in preview, creates and modifies semantic models in Fabric workspaces with nothing installed locally, and needs a Fabric tenant setting turned on. Microsoft advises against registering both at the same time.

Yes. The per-model setting that lets read-only users reach a model through Copilot, data agents and the remote Fabric and Power BI MCP servers is on by default, and it is not inherited by models built on top of another model. That is why we now agree AI access with the model owner as part of every handover.