Migrating process to Git Integration with Multi Tenancy

[JAnder]

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.

[v-prasare]

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

[v-prasare]

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