A finance reporting team running Power BI over Dynamics 365 Finance and Operations data has a familiar problem: exactly one person can safely have the working capital dashboard open at a time. Everyone else waits, or worse, someone opens the file anyway, makes a change, saves over a colleague’s unsaved edits, and nobody finds out until a client asks why a visual disappeared. That is not a hypothetical. It is how nearly every Power BI report built on top of Dynamics 365 or Dataverse data has been managed since the tool existed, because a .pbix file is a single binary blob. There is no diff, no merge, no pull request, just a file lock enforced by social convention. The Power BI PBIR format changes that mechanic directly, and as of May 2026 it became the default way Power BI Desktop saves new reports, which makes this less a curiosity for early adopters and more a decision every Dynamics 365 reporting practice needs to make on purpose.
PBIR stands for Power BI enhanced report format, and it replaces the older single-file report.json approach (itself an earlier attempt at the same problem, now referred to as PBIR-Legacy) with a folder of small, human-readable JSON files. Microsoft first shipped it as a Desktop developer mode preview several years ago, but the May 2026 update made it the default for both new PBIX files and PBIP projects, meaning teams that never opted into the preview are now creating PBIR reports without necessarily realizing the storage model underneath them has changed.
What the Power BI PBIR Format Actually Changes on Disk
Open a PBIR report’s project folder and you will find a definition directory containing a pages subfolder, a bookmarks subfolder, a report.json for report-level settings, and a version.json that records which format version the report requires. Inside pages, each report page gets its own folder with a page.json and a visuals subfolder, and inside that, every single visual on the page gets its own visual.json file describing its position, formatting, and query. A bookmark becomes its own file too. This sounds like a lot of small files for what used to be one, and it is, but that granularity is the entire point: a change to one chart’s conditional formatting now shows up as a one-file diff instead of an unreadable delta buried inside a compressed binary.
Each of these JSON files declares a public schema URL at the top, and Microsoft has published those schemas on GitHub, which means a report can be opened, validated, and even edited in VS Code with real IntelliSense rather than guesswork. Objects get 20-character generated identifiers by default (something like 90c2e07d8e84e7d5c026), which is ugly to read in a diff but can be renamed to something meaningful through Power BI Desktop, with the caveat that renaming requires restarting Desktop for the change to stick. There is also a lesser-known annotations feature: name-value pairs that Power BI itself ignores completely but that a deployment script can read, which turns out to be useful for marking which page should be the default landing page in a given environment or flagging a visual for environment-specific suppression.
The Git Workflow This Finally Enables
None of the file structure matters much without source control actually using it, and this is where the practical shift happens. A pull request against a PBIR report can now show a reviewer exactly which visual changed and how, the same way a code review shows a diff of a function. Two developers working on different pages of the same report can genuinely work in parallel and merge without one silently overwriting the other, something that was structurally impossible with a monolithic .pbix. Fabric’s own Git integration, which connects a workspace to Azure DevOps or GitHub, extends this further by tracking reports and semantic models at the workspace level and preserving folder structure in the repository, though it is worth being precise here: the file format reaching general availability in Desktop and Fabric’s Git integration support for report and semantic model items reaching full production maturity are two different milestones, and as of this writing the latter is still documented as preview for several connection scenarios, including reports tied to Analysis Services live connections.
A report’s connection to its semantic model is itself stored declaratively, through either a byPath reference that opens the model in full edit mode alongside the report, or a byConnection reference that opens the report in live connect mode with only report-level measures editable. Which one a team chooses affects how much of the semantic model layer gets included in the same Git history as the report, and it is worth deciding deliberately rather than by whatever Power BI Desktop defaulted to on first save.
Why This Matters More for Dynamics 365 Reporting Portfolios
Generic Power BI advice tends to treat this as a nice-to-have for BI teams in general. For a Dynamics 365 F&O or Business Central reporting practice specifically, it addresses a sharper pain point. These environments accumulate large report portfolios fast: financial statement packages, inventory and demand dashboards, project cost tracking, often built by a rotating cast of internal analysts and external consultants over several years. Ownership gets murky, undocumented changes creep in before a board meeting, and when something breaks nobody can say with confidence what changed or when. Power BI Desktop’s version history feature, which also reached general availability in the May 2026 wave alongside the default PBIR change, gives that audit trail natively inside the desktop tool for the first time, which is directly relevant to any organization treating financial report changes as something that needs a change management trail rather than an honor system.
Deployment pipelines benefit in a related way. A report promoted from a development workspace to test and then production can carry annotation-driven configuration differences (a different default page, a different data source binding) without manual reconfiguration at each stage, and the promotion itself becomes something a pipeline log records rather than something a person remembers doing.
Rolling Out PBIR Without Breaking Anything
The rollout mechanics are straightforward but deserve a plan rather than an ad hoc toggle. PBIR is enabled through Power BI Desktop’s preview features under Options, and existing PBIR-Legacy reports convert automatically on the next save, with Desktop creating a backup copy first. That backup detail matters because there is no supported rollback path once a report has converted; the backup is the rollback path, and it lives in a local temp folder with a 30-day retention window, not somewhere a team should rely on long term. The sensible sequence is to pick one lower-stakes report first, ideally something without heavy custom visual dependencies, convert it, get comfortable with the folder structure and the Git workflow in a sandbox repository, and only then extend the practice to the financial statement packages where a mistake actually costs something. Establishing a branching convention (a feature branch per report change, a pull request before merging to the branch a production workspace tracks) before the first real conversion saves a team from learning that lesson under time pressure.
What Still Doesn’t Work Smoothly
A few limitations are worth knowing before committing a whole reporting portfolio to this model. Edits made directly in a code editor do not sync live; the report has to be reopened in Power BI Desktop for those changes to take effect, so treat external JSON edits as a batch operation rather than a live-editing workflow. Two developers can still step on each other if they edit the same page at the same time rather than different pages, since the conflict resolution is granular but not infinite. Service-side limits apply too: a report tops out at 1,000 pages and 1,000 visuals per page, and resource packages are capped at 300 MB, ceilings that rarely matter for a typical operational dashboard but are worth knowing about before designing something unusually large. And a handful of connection types, including push datasets, live connections to on-premises Analysis Services, and older model versions, are excluded from Git integration support entirely for now.
None of that undermines the core shift. Power BI reports built on Dynamics 365 data have functioned for years as single-owner artifacts, reviewed by nobody, versioned nowhere, and handed off through tribal knowledge. PBIR does not fix that automatically, but it removes the technical excuse for not fixing it. The teams that treat this as an application lifecycle management decision, with branching conventions, review checklists, and a deliberate rollout order, will get real governance out of it. The teams that flip the preview toggle and keep working exactly as before will just have smaller binary files. At Routeget, we have been sequencing client Dynamics 365 F&O reporting portfolios through this conversion starting with the highest-change-frequency reports rather than the highest-visibility ones, on the theory that the reports changing every month are where a missing audit trail actually costs someone time.
#PowerBI #PBIR #GitVersionControl #DynamicsFinanceOps #ReportGovernance #MicrosoftFabric
No comment yet, add your voice below!