Delivering the same Power BI report to many tenants doesn't have to mean maintaining many semantic models. When the reporting logic is identical and only the data location changes, one parameterized model can serve every tenant. We learned this while building a reconciliation report for a multi-tenant data migration. Every tenant needed the same answer: did all the data arrive at the destination intact? Rather than cloning and editing a model for each tenant, we built one reusable model and moved the tenant-specific details into Power Query parameters. Here's how it works, and why it made onboarding a routine task instead of a development project. The challenge: The report had the same purpose for every tenant: compare source and destination data after migration and identify any discrepancies. However, each tenant had its own schemas. Without parameterization, onboarding a new tenant would require manually updating schema references throughout the model. As more tenants were added, this would create multiple copies of essentially the same model. This also increases the risk of inconsistencies. A fix applied to one model may not be applied to another, and over time the reports can start behaving differently. We wanted a process that was repeatable, consistent, and easy to maintain. The approach: Power Query parameters We added two parameters to the semantic model, and they became the only tenant-specific configuration: SourceSchema identifies the tenant's source schema. DestinationSchema identifies the tenant's destination schema. The server and database connection stay the same for everyone. Only the schema values change. Tenant SourceSchema DestinationSchema Customer A CustomerA_Source CustomerA_Destination Customer B CustomerB_Source CustomerB_Destination Every query in the model references these parameters instead of a hardcoded schema name. Tenant details become configuration, and the reporting logic stays untouched. Onboarding a new tenant in nine steps With the reusable model in place, adding a tenant follows the same checklist every time: Download or prepare the existing semantic model. Rename it for the new tenant. Copy the required report visuals into the new file, if needed. Publish the report to the right Power BI workspace. Open the model's transformation or parameter settings. Set SourceSchema and DestinationSchema to the new tenant's values. Apply the changes. Refresh the model. Validate the reconciliation results. No queries are rebuilt and no report pages are redesigned. The administrator changes two values and validates the output. Consistency, governance, and a word on security One of the biggest advantages of this approach is consistency. Every tenant can use the same semantic model design and reconciliation logic. Tenant-specific values are kept in parameters instead of being scattered throughout the queries. This also makes the process easier to document. The organization can define who is responsible for onboarding tenants, who can change parameters, how refreshes are performed, and what validation is required after each deployment. At the same time, tenant data isolation still needs to be handled through the appropriate database and Power BI security and permission model. Parameters should be treated as configuration, not as the only security control. Business benefits A parameter-driven model pays off in practical ways: Faster onboarding, because there is little to no development per tenant. Consistent reporting, because every tenant shares one model and one set of calculations. Lower maintenance, because a fix is made once and applies everywhere. Fewer configuration errors, because no one is hand-editing dozens of queries. Better scalability, because the effort per tenant stays flat as the tenant count grows. Simpler administration, through a documented, repeatable onboarding process. Above all, adding a tenant becomes an operational task rather than another development project. Conclusion When several tenants need the same Power BI reporting experience, a separate model per tenant usually isn't necessary. If the database structure is consistent and the main difference is the schema, Power Query parameters make one semantic model reusable across all of them. With SourceSchema and DestinationSchema as the only tenant-specific settings, the reconciliation logic stays standardized and onboarding stays repeatable. The result is one model, configurable tenant values, and reporting that scales with your tenant base.
