Get Help

Test a semantic model in a workspace

A published model is reached through the workspace's XMLA endpoint. One-time setup — a capacity that has the endpoint, a service principal with access — then a connection string, and the tests you wrote against the Desktop file run against the published model unattended.

Prerequisites

  • The workspace is on a capacity that exposes the XMLA endpoint: Power BI Premium, Premium Per User, or a Fabric capacity. Read access through the endpoint is on by default; the tenant setting Allow XMLA endpoints and Analyze in Excel with on-premises semantic models must be enabled (it is, unless an admin turned it off).
  • An identity that may read the model. For unattended runs that is a service principal — an app registration with a secret in Microsoft Entra ID. Your Power BI administrator does the one-time part: allow service principals to use Power BI APIs (tenant setting, usually scoped to a security group), then add the principal to the workspace with at least the Member role — Viewer is not enough for the endpoint. Microsoft’s walk-through: Automate Premium workspace and semantic model tasks with service principals.
  • The workspace connection URL: workspace Settings → Premium → Workspace Connection → Copy; it looks like powerbi://api.powerbi.com/v1.0/myorg/Sales%20Workspace.

Add the data source

Data sources → New data source: a name, technology Power BI Semantic Model (or MS Fabric Semantic Model — identical underneath), then the workspace connection URL, the model’s name, and the service principal as user and password — typed as %NAME% environment-variable references, never as the values. Studio writes the connection string for you.

Data sources:
- Name: sales model
  Provider: Dax@2
  Connection string: >
    Data Source=powerbi://api.powerbi.com/v1.0/myorg/Sales%20Workspace;
    Initial Catalog=Sales;
    User ID=%PBI_SP_USER%;
    Password=%PBI_SP_SECRET%;

PBI_SP_USER holds app:<application id>@<tenant id>, PBI_SP_SECRET the secret — see Work with secrets. The whole string may also be one variable. Every key: Dax@2.

Azure Analysis Services, SQL Server Analysis Services

Same provider, same tests; only Data Source changes — the asazure://… address for Azure Analysis Services (service principal the same way), the server name for SSAS, where a local instance takes Integrated Security=SSPI and no principal at all. Studio: technology Azure Analysis Services or SQL Server Analysis Services.

Write the tests

Exactly the tests of a Desktop file — a model is a model. Start from the project you used while building the file and swap the data source:

Tests:
- Name: Sales per year match the warehouse
  Suite: Model vs source
  First data source: sales model
  First query: |
    EVALUATE SUMMARIZECOLUMNS('Date'[Year], "Sales", [Total Sales])
    ORDER BY 'Date'[Year]
  Second data source: DWH
  Second query: SELECT YEAR(OrderDate), SUM(Amount) FROM fact.Sales GROUP BY YEAR(OrderDate) ORDER BY 1
  Expectation: sets match
  Key: 1
  Tolerance: 0.01

More on Test measures; the DAX without writing it: Get the DAX query behind a visual.

Without a service principal

Your own account works for an interactive session — Authentication left to the driver prompts you, MFA included — and it works only there: CAT opens more than one connection, so you confirm more than once, and an unattended run has nobody to confirm. Use it to try things; use the service principal for anything scheduled.

← Test a Power BI Desktop file
Get the DAX query behind a visual →