topic Re: Migrating process to Git Integration with Multi Tenancy in Developer

Migrating process to Git Integration with Multi Tenancy

JAnder — Fri, 13 Feb 2026 13:12:06 GMT

We have reports which are standard and deployed to 100s of customers. Each customer has their own workspace and database (schemas are the same). We use embedded reports in our application so we control the workspaces etc. Customers just see their reports.

Currently we have custom tooling written using the Power BI and Fabric Rest APIs. The existing release process involves

Import the pbix to workspace
Update the model connection string to point to client database associated with the workspace
Bind the model to the correct connection object for authentication (Workspace Identity)
Trigger a data refresh

For existing reports already on the workspace and not dependent on a model, we use UpdateReportContentInGroupAsync to update the report and maintain the ReportId.

So my question is what consideration are needed for migration to Git integration. I understand import will no longer be a thing, we will need to release by cloning standard reports over to the tenant release folder in the repo and then sync the workspace. But once done, how can connection strings be updated, can we still associate with a connection object for authentication?

I am struggling to find the right documentation for this. Deployment pipelines do not fit our model as we release from one standard report to hundreds of customers. It doesnt make sense to have Development/Staging/Production workspaces for each.

Re: Migrating process to Git Integration with Multi Tenancy

v-prasare — Tue, 17 Feb 2026 04:39:32 GMT

Hi @JAnder,

In your model, where a single set of standard reports is deployed to hundreds of customer-specific workspaces, Git integration should be viewed primarily as a source control and governance layer, not as a replacement for existing deployment automation.

With Git integration, PBIX import is no longer the deployment mechanism. Instead, standard reports and semantic models are stored once in Git and synchronized to tenant workspaces. However, Git sync does not currently support tenant-specific transformations, such as dynamically updating connection strings or binding models to workspace identity–based connection objects.

As a result, after syncing content from Git to a tenant workspace, you will still need to rely on Power BI / Fabric REST APIs to:

Update the semantic model connection string to the customer’s database
Bind the model to the appropriate authentication or workspace identity
Trigger dataset refreshes

This closely aligns with your existing tooling, with Git effectively replacing PBIX files as the artifact source.

Deployment pipelines are not a good fit for this scenario, as they are designed for fixed Dev/Test/Prod environments and do not scale when releasing a single standard solution to hundreds of tenant workspaces. At present, the most practical and scalable approach is a hybrid model: Git integration for managing and versioning shared artifacts, combined with REST-based automation for applying customer-specific configuration during deployment.

Given the importance of this scenario for embedded and multi-tenant solutions, it would be valuable to raise this as an idea or enhancement request in the Fabric Ideas - Microsoft Fabric Community forum, particularly around support for tenant-level configuration (connections, identity binding) as part of Git-based deployments.

Thanks,

Prashanth

Re: Migrating process to Git Integration with Multi Tenancy

v-prasare — Tue, 24 Feb 2026 11:22:35 GMT

Hi @JAnder,

This is a suggested architectural approach, and since there is no official documentation for this exact pattern, we couldn’t fully reproduce your scenario due to licensing, access limitaions in our environment.

If the required permissions and licensing are in place, could you please try this from your end and let us know the result? I can also share some internal reference documents privately if helpful.

Suggested approach:
Firstly, Create parameters for tenant-specific values

In Power Query Editor, go to Home → Manage parameters → New parameter and create the following parameters:

These values act as placeholders and can later be updated per customer (for example, through REST APIs after the report is published). Replace hardcoded connection values with parameters.

In Power Query Editor, select your main query and open Advanced Editor. Update the

parameterized query:

Source = Sql.Database(ServerName, DatabaseName)

This is the key change. once parameters are used, the dataset is no longer tied to a specific server or database. Once done push this template report to GIT and sync with customer workspaces.

For tenant-specific configuration, the workspace is updated to point to the customer’s data by modifying dataset parameters rather than changing the connection string directly: The configuration is performed using the Power BI REST APIs, where parameters such as server name and database name are updated at the dataset (semantic model) level
(Workspace → Semantic Model (Dataset) → Settings → Parameters).

Once the parameters are updated, the dataset is bound to the workspace identity using the same REST API–based credential and identity binding process. This ensures that authentication is handled through the workspace’s managed identity or configured credentials, without embedding sensitive connection details in the model.

After the parameters and credentials are successfully applied, a dataset refresh is triggered via the Power BI REST API. Upon completion of the refresh, the semantic model connects to the updated data source and loads Customer’s data correctly.

Required permissions:

Workspace access: The identity performing the action must be added to the target workspace as Member or Admin. Viewer access is not sufficient.

REST API execution: Updating dataset parameters, binding gateways, and triggering refresh must be done via Power BI REST APIs. UI access alone cannot perform these actions.

Service Principal: generally, automation and production scenarios, use an Azure AD App (Service Principal) instead of a user account.

API permissions (Application level)
The app must have:

Dataset.ReadWrite.All
Workspace.ReadWrite.All
Admin consent is required.

Tenant setting: In the Power BI Admin Portal, “Allow service principals to use Power BI APIs” must be enabled.

Thanks,

Prashanth

Re: Migrating process to Git Integration with Multi Tenancy

v-prasare — Mon, 02 Mar 2026 11:09:58 GMT

Hi @JAnder,

Just checking in to see if you got a chance to try implementing the suggested approach we shared earlier for Git integration with parameterized connections and REST API–based configuration.

Please let us know if it worked for you, or if you ran into any issues or have questions, we’ll be happy to help.

Thanks,

Prashanth

Re: Migrating process to Git Integration with Multi Tenancy

v-prasare — Thu, 05 Mar 2026 11:51:40 GMT

Hi @diablo9081,

As we haven'r heard back from you, Can you please confirm whether below suggest approach works for you? If you still have any questions or need more support, please feel free to let us know. We are happy to help you.

Thank you for your patience and look forward to hearing from you.
Best Regards,
Prashanth Are
MS Fabric community support

Re: Migrating process to Git Integration with Multi Tenancy

JAnder — Tue, 31 Mar 2026 14:40:10 GMT

Apologies for not getting back sooner, I have been on another project and didnt see this reply.

I think the problem with adding parameters to reports, is purely that we had an awful of lot of reports in pbix format. I did some testing and it looks like many of the REST API endpoints do still work, of course I cannot deploy with import anymore but I am wondering now if rewriting our custom tooling to wrap Git might be a better solution

Rather than using the import API it can run some git commands to move the reports into the relevant repo folders for deployment. Then we can trigger the workspace sync, update connection strings etc using the REST API as before.

I dont know if what we are doing is unique, it does seem to go against the way all the documentation suggests but we are multi-tenanted and have so many reports per tenant that manual editing is not going to be possible.
Hopefully once we have these in Git and are using the new formats, we could use AI for future mass editing if needed.

I appreciate your reply, my apologies it took me so long to acknowledge it.