Forum Discussion
Advocate ILooking for Best Practices for Multiple Developers Working on the Same Semantic Model in Fabric
Hi Karthik_P_V
Thanks for sharing the scenario.When multiple developers need to work on the same semantic model, I'd generally recommend treating source control as the source of truth rather than having everyone edit the model directly in the workspace.
PBIP together with Git/Azure DevOps is worth considering here. For semantic models, TMDL is especially helpful because model objects are stored in readable files, which makes reviewing changes and resolving merge conflicts much easier than relying on workspace edits alone.
A common approach is : Developer → Feature Branch → PR Review → Merge → Deploy
For larger teams, separate development workspaces can also help reduce conflicts, particularly when semantic models depend on workspace-specific Fabric assets such as Warehouses, Lakehouses, or SQL endpoints.
If two developers modify the same model object, Git merge/PR processes are typically used to resolve those conflicts before deployment rather than having one workspace change overwrite another.
The exact approach depends on how tightly coupled the semantic model is to workspace-specific artifacts, but in many projects Git-based development becomes the primary collaboration mechanism while Fabric workspaces are used mainly as development, test, and production environments.
Useful references:
Semantic model best practices for data agent - Microsoft Fabric | Microsoft Learnhttps://learn.microsoft.com/en-us/fabric/cicd/best-practices-cicd
Development Process in Microsoft Fabric - Microsoft Fabric | Microsoft Learnhttps://learn.microsoft.com/en-us/power-bi/developer/projects/projects-dataset
It would also be interesting to hear how other community members are handling semantic model co-development in Fabric, particularly where multiple developers need to work on the same model simultaneously.
Hope this helps!!
Thank You.
Community ChampionHi Karthik_P_V,
I agree with the Git/PR approach already suggested, and I would make one point even stronger: I would avoid having multiple developers directly edit the same semantic model in one shared Fabric workspace.
Microsoft's current Fabric development-process guidance describes a workspace as a shared runtime environment, where changes made directly affect the other users in that workspace. Their Git best practice is therefore for developers to have separate runtime environments.
A pattern I would use is:
Developer A -> feature branch -> development workspace
Developer B -> feature branch -> development workspace
-> PR / review
-> merge to main
-> deploy through shared Dev/Test/Prod environments
For semantic models, PBIP + TMDL is useful because the model definition is stored in source-control-friendly files rather than one opaque artifact. Microsoft's PBIP semantic-model documentation specifically positions TMDL as improving Git diffs, merge-conflict handling and co-development.
That does not mean Git resolves semantic conflicts automatically. If two developers change the same measure/table definition, I would still resolve and review that conflict in the PR before syncing the merged version back to Fabric.
For Direct Lake development there is an additional consideration. Microsoft recommends that, when using a PBIP connected to a remote Direct Lake semantic model, each developer works against their own private remote semantic model to avoid overwriting another developer's changes.
For the workspace-specific Warehouse / SQL endpoint dependencies, I would also avoid assuming every reference will automatically rebind between developer workspaces. Fabric's dependency-binding documentation shows that some references use portable logical IDs while others retain workspace-specific IDs and require parameterization or manual rebinding.
So I would separate the concerns:
- individual developer workspace/branch for isolation
- PBIP/TMDL + Git PRs for semantic-model source control
- shared integration workspace only after merge
- deployment pipelines / parameterization for Test and Production
- avoid direct concurrent editing of the same live semantic model
In my view, the shared workspace should be an integration/runtime environment, not the place where several developers simultaneously author the same model.
AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.
Advocate IThank you for your help. I'll try this approach and post an update here.
v-aatheequeCommunity Support
Hi Karthik_P_V
Have you had a chance to look through the responses shared earlier? If anything is still unclear, we’ll be happy to provide additional support.