Forum Discussion
UpdateFromGit fails with CopyOverwriteUsageException - no API option to bypass deletion consent?
Hi yazdanb,
XMLA schema pre-apply (your CopyOverwriteUsageException workaround): ✅ Works with a Service Principal, it can connect to the XMLA endpoint and run the TMSL alter for column type changes. Your existing RLS role definitions in model.bim survive untouched.
updateFromGit with a semantic model: ⚠️ Unreliable with a Service Principal. In practice you need to run it with the credentials of the semantic model owner via a PAT token. (Microsoft Fabric Community)
RLS role membership via XMLA: ❌ Hard block. Service Principals cannot be added as model role members through the XMLA endpoint. (Microsoft Learn) Role definitions (the DAX filter expressions) are fine, but assigning users to roles is not.
Solution: Use your Service Principal for everything except the semantic model Git sync step, swap in a dedicated deployment user's PAT just for that one call. It's not clean, but it's the only reliable path today.
Hi yazdanb,
Hope you're doing well!
This is the workaround that actually works for schema-breaking changes in an unattended pipeline. Instead of going through updateFromGit, you apply the schema change directly to the semantic model via the XMLA endpoint using a TMSL alter script. This requires your workspace to be on a Premium or Fabric F/SKU capacity because it requires XMLA read/write access. Microsoft Fabric Community
Your pipeline would:
- Fetch the new model.bim from your ADO repo at the target commit
- Connect to the XMLA endpoint (powerbi://api.powerbi.com/v1.0/myorg/YourWorkspace)
- Send an alter TMSL command to apply column type changes directly (this bypasses the Git sync gate entirely)
- Then call updateFromGit normally, since the schema is already aligned, there's no "data deletion" risk detected
The key here is that the XMLA path doesn't go through the same consent gate. As of June 2025, all Power BI and Fabric capacity SKUs support XMLA read/write operations by default, so you shouldn't need to ask your capacity admin to enable it anymore. Microsoft Fabric
Hope this helps. Feel free to ask me questions if needed, and don’t forget to like (give kudos) & Accept as Solution if this guidance worked for you. That's motivate me to keep helping.
Best regards,
Oussama (Data Consultant & Fabric's Expert)
Thanks Oussama. Could this work if we have RLS enabled and are using a Service Principal for deployment and updates?
