What goes wrong when two people edit the same Power BI semantic model

#collaboration #power-bi #workflow

Power BI's default assumption is that one person owns the model. That was

true in 2016. It isn't true in 2026. Most BI teams we talk to have at

least two full-time people editing the same model, plus one or two

part-time contributors from elsewhere in data engineering.

Here is what actually breaks, in order of how often we see it.

Failure 1 — The silent merge-overwrite

Alex opens the PBIP on Monday. Ben opens it on Tuesday. Both make local

changes. Ben saves last. Alex's change is gone.

Why it happens: Power BI Desktop doesn't have a conflict-detection

story. The file on disk is the latest save. There is no "pull before

push."

What actually fixes it:

• Edit through a format that Git can reason about (PBIP + TMDL).
• Require review before apply — so the save is never the last-writer.
• Soft-lock a table while someone is editing it, with a visible presence

indicator.

Failure 2 — Renamed column, broken measures

Chloe renames Order_Date to Order_Date__deprecated because she's

mid-migration. She doesn't scan the 47 measures that reference it. The

next scheduled refresh fails at 6 a.m. with a cryptic error that nobody

wants to read at 6 a.m.

Why it happens: no compile-time guarantees in DAX. A measure that

references a deleted column silently becomes invalid.

What actually fixes it:

• Run a static dependency check before any applied change.
• Treat "measure references missing column" as a blocker, not a warning.
• Surface the 47 affected measures before the change is applied,

with the option to batch-patch.

Failure 3 — The "two truths" problem

Dev has [Revenue] defined one way. Prod has it defined a different way

because somebody hot-fixed it. The numbers on dashboards diverge by

2.7%. Nobody notices until the board meeting.

Why it happens: Power BI doesn't treat a semantic model like code.

There is no "diff of record" between environments.

What actually fixes it:

• Scheduled drift scans (PBIP-to-PBIP) between dev and prod.
• Auto-generated re-sync CRs when drift is detected.
• A clear convention that prod is a promotion target, not an editable

environment.

Failure 4 — Review rubber-stamp

Bryan opens the PR, sees 1,200 lines of TMDL diff, and writes "LGTM." The

bug ships.

Why it happens: TMDL diffs are hard to read because the surface area

is huge and most of the change is reformatting.

What actually fixes it:

• Show the CR, not the diff. A CR is "add measure % Partner Channel as

DIVIDE(...)" — two lines of semantic intent.

• Pair every semantic intent with an automatic impact report.
• Require reviewer to check at least one box on the impact report before

approval.

Failure 5 — Lost context

"Why does Revenue (old) exist?"

Three months of Slack searching, nobody remembers. It's now a dependency

of an executive dashboard. Removing it breaks the dashboard. Keeping it

wastes memory and makes future refactors harder.

Why it happens: the model is the only record of what happened.

Tickets, Slack threads, and whiteboard photos aren't searchable from

Power BI.

What actually fixes it:

• Every change request carries the ticket and the reviewer comment with

it into the model's audit row.

• "Why is this here?" becomes a one-click query against an immutable

audit log.

Where BiMA·gov fits

We didn't invent any of these failure modes — every BI team you can

name has written a Notion doc about them. What BiMA·gov does is turn the

fixes into defaults instead of conventions:

• PBIP + TMDL, not .pbix, for editing.
• Review before apply, enforced.
• Immutable audit log for chain-of-custody.
• Drift scan on a schedule, not when someone remembers.
• Dependency graph that answers "who uses this?" in one click.

If your team is below 3 people, you probably don't need us. Above 3,

the "conventions" approach starts costing you Friday afternoons.