UpdateFromGit fails with CopyOverwriteUsageException - no API option to bypass deletion consent?

[yazdanb]

We have an Azure DevOps pipeline that calls the Fabric REST API (POST /v1/workspaces/{id}/git/updateFromGit) to sync a workspace from Git. When a PR contains column data-type changes in a semantic model (e.g. double → int64, double → string), the operation fails with:

GitSyncFailed > CopyOverwriteUsageException:
"Dataset {id} changes will cause data deletion."

In the Fabric UI this is solvable — Source Control → Update → "Update Anyway". We need to do this unattended from a pipeline.

What we have tried:

1. clearValues first — emptying the dataset before syncing. Failed. The gate is a schema check, not a data check. Fires even on empty tables.

2. updateDefinition to pre-apply the new schema — fetching model.bim + definition.pbism from ADO at the target commit and calling POST /semanticModels/{id}/updateDefinition. Returns HTTP 202 then polls to Failed with RequiredOptionsMissing. The error body contains "parameters": [{"name": "optionName"}] — the option name slot is left blank, so we cannot tell what option is needed.

3. Various options flags on UpdateFromGit — tried allowDataDeletion, allowDataLoss, allowOverwriteItems, allowOverrideUsage, allowCopyOverwrite, allowSchemaChange, forceOverwrite. All silently ignored. CopyOverwriteUsageException still fires.

Question: Is there a REST API parameter (on either updateFromGit or updateDefinition) that provides the same consent as the "Update Anyway" button in the UI? If so, what is the correct option name? The RequiredOptionsMissing error strongly implies one exists but the name is not documented. If not, is there a workaround like clearing the data first and then applying the updates? Thank you!

[oussamahaimoud]

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.

[v-sshirivolu]

Hi @yazdanb,

Based on the official Microsoft Fabric REST API documentation, the updateFromGit API (POST /v1/workspaces/{workspaceId}/git/updateFromGit) includes an options object in the request body, however, the documentation does not define any parameters related to data deletion consent, schema override, or similar functionality. The only option reflected in usage examples is allowOverrideItems, which allows overriding existing items during the update operation. The documentation does not describe any additional flags or parameters that would correspond to confirming potentially destructive changes.

Additionally, the official documentation does not mention any REST API mechanism equivalent to the Fabric UI’s Update Anyway confirmation, nor does it document a way to provide consent for operations that may result in data deletion during a Git sync. As a result, based strictly on the documented API surface, no such capability is currently described for use in automated or programmatic scenarios.

Documentation Reference

Git - Update From Git - REST API (Core) | Microsoft Learn

[v-sshirivolu]

Hi @yazdanb ,

I hope the information provided above assists you in resolving the issue. If you have any additional questions or concerns, please do not hesitate to contact us. We are here to support you and will be happy to help with any further assistance you may need.

[oussamahaimoud]

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:

1. Fetch the new model.bim from your ADO repo at the target commit
2. Connect to the XMLA endpoint (powerbi://api.powerbi.com/v1.0/myorg/YourWorkspace)
3. Send an alter TMSL command to apply column type changes directly (this bypasses the Git sync gate entirely)
4. 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)

[yazdanb]

Thanks Oussama. Could this work if we have RLS enabled and are using a Service Principal for deployment and updates?