User-defined functions (UDFs) in Power BI let you build reusable, automated tests for your semantic models — so you catch broken measures, duplicate rows, and faulty relationships before they reach your reports. This article walks through how to use UDFs alongside PQL.Assert to standardize testing across your team, and how to automate those tests with Power Automate or a Fabric Notebook.

Reuse is a very important term in DataOps. It is defined as the practice of leveraging existing components, code, or processes across multiple projects to reduce redundancy and improve consistency.

However, when it comes to Power BI, reusing DAX measures across projects was a difficult ‘copy and paste’ job. For my teams, we used DAX measures to help with testing our semantic models, but ensuring consistent testing conventions (and standard schemas of the tests) required lots of manual review.

Thankfully, that changed in late 2025 when Microsoft introduced User Defined Functions (UDFs) for Power BI. In this article, I’ll demonstrate how to use UDFs for testing, plus how to standardize the way teams test their models.

Why is it important to test semantic models?

Many folks ask me, “why would you test your model?” Humans are fallible, so the semantic models we build are fallible as well. It’s easy to write a DAX measure that doesn’t properly handle filter context and results in inaccurate summations when a slicer filters the model.

It’s also easy to leave a filter in a step in Power Query when debugging your transformations, resulting in rows being accidentally removed from the model (not that I have ever done that!)

We should not only test to avoid repeating past mistakes, but for parts of the model we anticipate would have detrimental effects on reports. For example, columns used in relationships, often-used DAX measures, etc.

From a technical perspective, DAX and Power Query are code. Yes, they are maybe somewhat abstracted by low-code tools, but code should be tested nonetheless.

How to use user-defined functions for testing in Power BI

I’ll run through the process step-by-step. First, the setup. You’ll need to specifically turn on UDFs, since it’s currently (as of March 2026), a preview feature:

How to import PQL.Assert

While UDFs are a new concept to Power BI, the idea behind them exists in many other programming languages to share and reuse code. C# has NuGet, JavaScript has npm, and Python has PyPI.

Thankfully, the team at SQLBI introduced DAXLib. This site has a catalog of UDFs organized into packages which serve different purposes. There are ones that help build SVGs for visuals and others that help with calculating industry metrics.

The one that assists with building tests, however, is PQL.Assert. It’s an open-source library I helped develop.

Here’s how to import PQL.Assert:

Now, open your model in Power BI Desktop.

PQL.Assert provides a comprehensive set of assertion functions organized into several categories:

How to build your first test with Power BI user-defined functions

Let’s say you depend on an upstream SQL provider to provide you data for part of your model. From time to time they truncate the tables to hydrate them with the most up-to-date data.

However, their routines sometimes hydrate data with duplicates. This led to inaccurate calculations, so you had to put Power Query in place to remove duplicate rows.

Of course, you’d now like to ensure that those columns stay distinct, and avoid getting calls about calculations looking wrong. How would you write that test? Let’s find out.

First, open your model in Power BI Desktop and go to DAX Query View:

Enter PQL.Assert and the IntelliSense will display a wide array of functions for testing. You can see all of them listed here. But, for now, we will use PQL.Assert.Col.ShouldBeDistinct (in turn, ensuring that all column values are unique.)

Click the Run button, check the results, and then you can click “Add to Model”:

All test functions return results following a standard schema:

This test now stays with the model, so it can be validated any time the model is opened.

How to automate testing with user-defined functions in PowerBI

Manual testing is fine, but what about running these tests in the service? Can we automate them? Well, yes. There are two easy options:

The Power Automate approach to testing (step-by-step instructions)

The PQL.Assert repository includes a ready-made Power Automate solution you can import directly. You can download it from the examples/power-automate folder in the PQL.Assert GitHub repository.

The solution ZIP file (named PQLAssertviaPowerAutomate_x_x_x_x.zip, where x_x_x_x will be a version number) contains a pre-built flow that handles test discovery, execution, and result evaluation for you.

Here’s how to set up automated testing with Power Automate, step-by-step:

Once imported, the flow does the following:

Retrieves tests by executing PQL.Assert.RetrieveTestsByEnvironment against your semantic model. This is the V1 function, which uses only INFO.FUNCTIONS and is compatible with the Power Automate “Execute Dataset Query” action.

It returns a table of all functions ending with .Test or .Tests that match your target environment (e.g., .PROD. or .ANY.):

Parses the results to extract the list of test function names from the response:

Executes each test by running a “Run a query against a dataset” action for each discovered test function. For example:

EVALUATE DataQuality.ANY.Tests()

Evaluates the Passed column and checks for any rows where Passed = FALSE:

This template allows you to handle test results however you see fit. The flow can be extended to do things like save results to SharePoint, post failed test results to a Microsoft Teams channel for immediate action, or send an email notification. The options are nearly endless.

Important note: The Power Automate approach uses the V1 functions (PQL.Assert.RetrieveTests / PQL.Assert.RetrieveTestsByEnvironment). The V2 functions use INFO.USERDEFINEDFUNCTIONS and INFO.ANNOTATIONS, which are not supported in the Power Automate Execute Dataset Query action.

This also means the Power Automate approach does not support Row-Level Security (RLS) testing via user impersonation. If you need RLS testing, use the Fabric Notebook approach below.

How to use the Fabric Notebook approach for testing (step-by-step)

The PQL.Assert repository also includes a ready-made Fabric Notebook you can upload directly to your workspace. You can download it from the examples/fabric-notebook folder in the PQL.Assert GitHub repository.

The notebook (RunPQLAssertTests.ipynb) is a multi-workspace test runner that discovers all semantic models in each workspace, retrieves PQL.Assert test functions, and executes every test.

It also includes support for Row-Level Security (RLS) impersonation, which is a key advantage of this approach versus the Power Automate approach.

This support of RLS testing works as so: when a test function has the PQLAssert_ImpersonatedUserName annotation, the notebook will execute the test as that user using the semantic-link-labs impersonation API.

This lets you validate that your RLS rules are working correctly – something the Power Automate approach cannot do.

How to add annotations in the TMDL view

To enable RLS impersonation for a test, you need to add a PQLAssert_ImpersonatedUserName annotation to the test function in the TMDL view.

When you save your model in Power BI project format (.pbip), each DAX Query View tab’s test function is stored as a TMDL file. You can add the annotation directly in the TMDL source. For example, in the PQL.Assert test suite, there is an RLS test defined in the DAX Query View:

When this test is added to the model via “Add to Model,” the corresponding TMDL file (found in the TMDLScripts folder of your .pbip project), will look like this:

The annotation PQLAssert_ImpersonatedUserName = user@contoso.com line tells the notebook to execute this test function as that user. When the notebook calls PQL.Assert.RetrieveTestsByEnvironmentV2, it reads this annotation and applies impersonation automatically:

How to set up automated testing with the Fabric Notebook (step-by-step)

Here is a walkthrough to set up automated testing with the Fabric Notebook:

The Fabric Notebook then handles the rest automatically:

Important tip: the notebook identity (or the capacity admin token) must have Build access (at a minimum) on each target workspace. For impersonated tests, the workspace must use RLS, and the target user must exist in the tenant, with the appropriate role for the semantic model.

These steps are the same for other models, too

The great news is, these steps are the same for other models as well. You just have to alter the tests for your specific requirements. By following this approach, we are effectively reusing the testing framework with PQL.Assert across all of our semantic models.

And, by bringing tests into the model itself, they can be executed locally in Power BI Desktop during development, and remotely in the Power BI service through Power Automate or Fabric Notebooks.

Better still, the automated testing behaves the same regardless of where it runs, simply because we’re reusing PQL.Assert functions across models to identify tests and execute tests consistently. That is the power of reuse.

Any thoughts or feedback? I’d love to hear from you. Feel free to drop a comment below.