Editing Semantic Models in the Service + TMDL View & Best Practices
- Jihwan Kim
- 2 hours ago
- 4 min read
In this writing, I’d like to share how I started learning to edit semantic models directly in the Power BI service and how TMDL (Tabular Model Definition Language) fits into this new workflow. I’ll walk through what I tried, what worked, and some small lessons I learned while experimenting with TMDL.
Why I Tried Editing Models in the Service
Like most BI developers, I’ve built models exclusively in Power BI Desktop for years. Every time I wanted to tweak a measure or add a relationship, I had to:
Open the PBIX file,
Make the change,
Save and re-publish it.
It worked, but for collaborative teams, it’s slow and error-prone — especially when I am managing multiple environments or large semantic models shared across workspaces.
When Microsoft announced that we could edit semantic models directly in the Power BI service, I wanted to see whether it could simplify versioning and CI/CD. (Microsoft Learn – Edit semantic models in the Power BI service)
Step 1 – Opening the Model in the Service
You can open a semantic model right from your workspace in the Power BI service.
Go to your workspace → click three dots located after the name of Semantic model.
Click Open data model.
The Model view opens in the browser — it looks like a simplified version of Power BI Desktop’s Model tab.
Change to Editing mode.
What you can do:
Add or modify DAX measures.
Create or delete relationships.
Adjust data categories or format strings.
Rename tables or fields.
Note: Editing requires proper permission.
Step 2 – Adding or Modifying Measures
Let’s say I want to create a new measure for Total Sales Amount:
Select the table where I want the measure to live.
Click New measure (top toolbar).
Enter DAX expression in the formula bar:
Press Enter → the measure is saved immediately in the online model.
I can also edit existing measures in the browser — just select them in the Fields pane, update DAX, and press Enter.
This is fast for quick fixes, especially when validating business calculations without republishing PBIX files.
Step 3 – Exploring the TMDL View
TMDL (Tabular Model Definition Language) is where this gets interesting. It’s a text-based representation of the semantic model. (Tabular Model Definition Language (TMDL))
When the workspace is connected to Git, each semantic model can be stored as a set of .tmdl files.
To see this in action:
Connect the workspace to a Git repo (requires Fabric or Power BI Premium).
Go to workspace settings → Git Integration → connect to your repo.(Get started with Git integration)
When connected, Power BI will represent the model in the repo using TMDL files.
Each table, measure, and relationship becomes part of a structured TMDL file.
I can open this file directly in VS Code or any text editor to see and review changes.
Step 4 – Managing Model Changes
Once TMDL files are in my Git repository, I can start treating my semantic models as code.
Typical workflow:
Developer edits model in Power BI service → commit syncs to Git.
Reviewer checks the TMDL diff in Git before merge.
Being able to review model logic like this — outside of Power BI — is a big win for governance and collaboration.
Common Pitfalls I Hit
While this setup feels powerful, a few issues stood out during testing:
Not all features supported yet: Some Desktop modeling functions aren’t fully available in the service.
Large models load slower: The web model editor can lag with very complex schemas.
Sync discipline is critical: Forgetting to sync to Git causes conflicts quickly.
Permissions matter: If a user edits without Git access, changes can’t be committed.
Still, none of these are deal-breakers — they’re just the realities of a feature still evolving.
Why This Changes How I Work
I can:
Fix or add measures directly in the browser without publishing new PBIX files.
Keep all changes transparent in Git using TMDL.
Apply review processes like you would with any codebase.
It’s the same modeling logic, but now it fits into a governed, collaborative process that scales.
Best Practices I’ve Learned
As I tested this in a multi-developer setup, a few practical lessons stood out.
1. Enforce role-based editing Restrict “Edit model” permissions in production workspaces. Only modelers should have the ability to modify measures or relationships directly in the service. Everyone else should consume or comment.
2. Keep Git as the source of truth Even though I can edit in the service, the TMDL version stored in Git should always be the canonical reference. Any in-service edits should be synchronized back to Git immediately to avoid drift.
3. Review before merging Because TMDL is text-based, I can easily review DAX measure changes, relationships, or object additions —something that was nearly impossible with PBIX files.
4. Document inside TMDL Add comments or annotations directly in TMDL files to describe measure intent or dependency rationale. These notes are valuable for both governance and onboarding.
Editing semantic models directly in the Power BI service — together with TMDL and Git integration — is more than a convenience feature. It’s a step toward semantic-model-as-code. It allows teams to manage BI assets with the same rigor as software engineering: version control, collaboration, and review.
I hope this helps having fun in experimenting with in-service modeling and TMDL in Microsoft Fabric.
Comments