Back to Blog

Manage DirectQuery Connections to a Published Power BI Semantic Model

November 7, 2026•6 min read•Michael Ridland

A few years ago I inherited a Power BI estate for a logistics client that had quietly become a house of cards. The central semantic model had been published with care. Then a team in another division connected to it with DirectQuery, built a composite model on top, added their own measures, and published that. A third team did the same thing on top of their model. By the time we looked, there were four layers of models, and nobody could say with confidence which version of "on-time delivery" the board was looking at.

That is the chaining problem, and it is more common than most people admit. Power BI makes it easy to connect to a published semantic model with DirectQuery, and it lets you build a composite model on top. That's useful for an analyst who needs to extend a model quickly. It's a headache when the extension becomes its own source of truth.

Power BI has a setting to discourage those connections. It's not a complete control, and the documentation is clear about that. But used properly, it makes the chain much harder to form in the first place.

What DirectQuery connections to a published model mean

By default, once you publish a semantic model to the Power BI service, anyone with the right permissions can make a DirectQuery connection to it. They can use that connection to create new composite models that sit on top of the original. Each layer can add its own calculations, relationships and tables, which is where definitions start to diverge.

Microsoft's documentation calls this chaining. The concern is not that composite models are bad. It's that the original model stops being the single place where a measure is defined. Once two or three layers exist, the same measure name can mean slightly different things depending on which report you open.

In a lot of organisations, that's a governance question more than a technical one. Finance wants one revenue figure. Operations wants one utilisation figure. Chaining makes both harder to guarantee.

How to discourage DirectQuery connections

The supported route is the Power BI Desktop setting:

  1. In Power BI Desktop, go to File, then Options and settings, then Options.
  2. Under Current File, select Published semantic model settings.
  3. Choose the Discourage DirectQuery connections option and select OK.

Then publish the model. The setting travels with the model, so anyone who later tries to connect to it with DirectQuery should find that the connection is disabled.

If you manage models through tooling rather than Desktop, the documentation describes a third-party route. You set the DiscourageCompositeModels property on the model to True. That's useful for teams who script their deployments, and it's worth putting into your release checklist so it isn't forgotten after a rebuild.

The caveat that matters

The documentation says Power BI honours this setting and disables DirectQuery connections, but third-party tools might not. That is the sentence I would underline in any governance document.

In practice, this means the setting is a guardrail for the Power BI service and Power BI Desktop. It is not a lock on the data. If someone uses an external tool that connects to the semantic model through the XMLA endpoint or another client, they may be able to build what they want regardless of the flag. I have seen teams treat this setting as a security control. It isn't one, and it shouldn't be described to a board as one.

The right way to think about it is as a signal of intent combined with a default that makes the wrong thing harder. If you need to prevent access to data, that's a permissions and workspace design question. Row-level security, workspace roles and a sensible separation between certified models and personal experimentation do that job. The discourage setting sits alongside those, not in place of them.

Where I think the feature is still rough

There are a few things I'd like Microsoft to tighten.

First, the documentation's date stamps suggest this page has not changed much in a while, and the guidance is thin on what happens to composite models that already exist when you flip the setting. If you have live chains in production, you need to know whether the discouraged state affects them, and the page doesn't spell that out. Our approach is to test on a copy first and not assume.

Second, the setting is per model, which is correct, but it's easy to miss when models are copied or rebuilt. A new version published from a fresh file may not carry the intent the old one had unless someone set it again. That's a process problem, but the tooling could make it harder to forget.

Third, and this is my personal frustration, the phrasing "discourage" is accurate but soft. Business owners read it as a policy statement rather than a technical limit. I would prefer the tooling made the distinction clearer in the UI.

What we recommend on engagements

We now treat chaining as a governance item in the first week of any Power BI engagement. The steps are not complicated:

  • Inventory which semantic models are published and which have downstream composite models built on them. The admin tooling and the workspace lineage view will get you most of the way.
  • For certified models that feed the executive reporting, enable the discourage setting in Desktop and make it part of the publish checklist.
  • Where a legitimate need for extension exists, agree on a documented route. Usually that means a request to add the measure or table to the source model, rather than building a parallel layer.
  • Don't describe the setting as security. Pair it with workspace permissions and row-level security wherever data access actually matters.
  • Re-check the setting after any rebuild or redeploy. We keep it on the same checklist as refresh schedules and gateway credentials.

One practical note for teams that have already got chains in place. Don't try to rip them out all at once. Map the dependencies first, decide which layer is the source of truth for each key measure, and move definitions up to the model that should own them. It is slow work, but it's the only way to end up with one number for each metric without breaking the reports people rely on every morning.

The bottom line

DirectQuery connections to a published semantic model are useful, and blocking them everywhere would make life harder for your analysts. The discourage setting gives you a sensible default for models that matter, and it stops the casual chain from forming. Just be clear about what it does. It honours the intent inside Power BI. It does not stop a determined tool from connecting somewhere else.

If your Power BI estate has grown into layers that nobody fully understands, our Power BI consultants can run a lineage review and help you decide which models should own which measures. If you are weighing up where those models should live as part of a broader data platform, our Microsoft Fabric consultants can help you design the structure before the next layer appears.

Source: Manage DirectQuery connections to a published semantic model (Microsoft Learn)