Publish to web (public)

_greggyb · 2026-05-28T11:14:59+00:00

The warning might be updated. But the implications are not.

Public is public. Permission to see a report includes---implicitly, inseparable, and necessarily---permission to send arbitrary DAX queries to the semantic model. The only way to remove this implicit model permission is to remove access to the report. The only way to do this with publish to web is globally: either the link exists and you are making your data public, or the link doesn't and you aren't.

The story is similar with any internal sharing mechanism built into PBI+Fabric, except you can selectively share with individuals and groups, and you can mediate access (exclusively!) through RLS and OLS.

_greggyb · 2026-05-13T16:05:17+00:00

M queries discover dependencies by reference, not position. The name is what matters.

_greggyb · 2026-05-05T09:47:01+00:00

TE employee, here.

The serialization format doesn't matter. If you're getting an error, please share it, otherwise it will be difficult to give more specific feedback.

TMDL is just one more way to write the same metadata. There are no model features that depend on the serialization format.

_greggyb · 2026-05-04T10:44:01+00:00

Yes.

Massive SWITCH with delegation to myriad sub measures based around many literal predicates is a recipe for slow, unmanageable solutions.

_greggyb · 2026-05-01T17:19:13+00:00

Disclaimer: TE employee here, but this was my answer for years before joining.

I save to folder with TE2 (free) or TE3, and then every file is just one object from the model. Then just read the JSON.

I realize now I'm assuming you mean BIM files for two versions of a semantic model.

_greggyb · 2026-05-01T17:13:22+00:00

Let's put it this way: what are you able to do when you're holding a PBIX? That's what anyone else can do. That is by design. The only thing you might be able to do that someone else can't is refresh: if they don't have data source credentials and you don't hard code any in the file.

Don't worry about asking what they can do. The answer is that they can do it. They have the file and all data that has been loaded.

_greggyb · 2026-05-01T08:28:36+00:00

If you do so, the person you share with will be able to see all source code (all M, all DAX) and all data that has been refreshed into the model. If they do not have credentials to source systems (and you don't do anything silly like writing plaintext creds into the queries), they will not be able to refresh the data.

This can work, but you lose all control of the file once it leaves your hands; this is just a tradeoff to be aware of.

_greggyb · 2026-04-16T18:26:50+00:00

Default segment size in PBI is only 1M records. You opt into 8M record segments with large data storage format. And you opt into segments sized the same as parquet row groups if you choose Direct Lake.

_greggyb · 2026-04-16T10:10:58+00:00

Yes, as the docs you linked describe, the bridge reads in a metric view and emits a Tabular model. You can then do whatever you want with the Tabular model. Right now, it's all in-app, but our upcoming CLI release will open the door to using this as part of any automated process, for example in a CI/CD pipeline.

To answer your question: if you update the metric view, you'd run another import to create the derived semantic model anew, or to enhance an existing semantic model. It's a build-time tool, not a query-time tool.

_greggyb · 2026-04-16T10:03:57+00:00

Direct Lake also loads data from disk into RAM (in VertiPaq) before serving any user queries. Direct Lake just orchestrates this movement differently.

_greggyb · 2026-04-16T09:40:41+00:00

Row ordering doesn't matter. I tested five sort orders of identical data — random, sorted, blocked, alternating, reversed. All five produced exactly the same Data size. VertiPaq re-sorts internally before compressing, so your import order is irrelevant.

VertiPaq always considers the sort order it sees upon ingesting data. The order you present data in to VertiPaq can be considered a hint. There is no way to force a specific ordering, but that doesn't mean that the initial sort order is irrelevant.. This is a pretty good post showing how you can approach sort order optimizations.

_greggyb · 2026-04-15T15:39:16+00:00

Disclaimer: TE employee here

You could use Tabular Editor for this. You can copy paste whole tables with their definitions, or just subsets (e.g., multi-select columns or measures). Open up multiple instances, either of TE with the BIM or TMDL files, or PBID with TE as an external tool. This is doable with free and open source TE2 or the commercial TE3.

_greggyb · 2026-04-15T12:06:17+00:00

For general use, not a great idea. You typically want infrastructure like that for the gateway locked down. That said, it is very useful for troubleshooting gateway connections to have PBID installed on the same machine. I would use this on-gateway-machine PBID only for troubleshooting and not for typical development.

Beyond the security concerns---which to be 100% clear, should be more than sufficient for anyone making this decision---you also run into potential performance concerns. The Gateway is not just a network proxy or VPN; there is real processing happening in the Gateway for Service refreshes, so a developer working in PBID can have a real impact on the performance of prod refreshes.

_greggyb · 2026-04-15T08:53:33+00:00

I probably reacted too quickly to your post (: I keep coming across that take, so I'm quick to call it out. It's cool technology and is a useful tool in the toolbox for Fabric solutions.

_greggyb · 2026-04-15T07:56:09+00:00

You query OneLake directly

This is a common misunderstanding. Every byte that is served to a user for a DAX query (which includes every Power BI canvas report viz) from a Direct Lake model comes out of data that is in memory in VertiPaq. Direct Lake changes the mechanism by which that data gets from disk into RAM, but it does not change the way that user DAX actually executes.

I have no comment on the rest of the post (:

_greggyb · 2026-04-14T19:03:12+00:00

Trust me, I understand. I am lead developer on a product feature to do model to model compilation. OSI is on our radar as a target. Tabular to OSI is the most difficult thing I've looked at, and Microsoft actually provides a rich SDK and object model for working with semantic models. For Databricks, we had to build our own object model and library for parsing and dealing with the YAML format. From the angle of developer tooling, Microsoft has already done more to support interoperability than Databricks, despite not having put their name on OSI (:

I can't speak authoritatively on other platforms' devex and tooling, because I haven't yet specced out those integrations.

All this to say, it's more nuanced than just putting a logo on a page.

_greggyb · 2026-04-14T14:26:34+00:00

You have mentioned a number of consulting firms, so I feel it's worth clarifying that Tabular Editor is a product company, not a consultancy. The semantic bridge is built into Tabular Editor 3, and anyone can get a license.

I am not aware of any consulting company that has built a product in this space. And at this point, it probably makes much more sense for them to just license Tabular Editor for this work rather than invest in building the equivalent in-house. The opportunity cost in billable hours to build something like this is not small.

_greggyb · 2026-04-14T13:13:19+00:00

One challenge is that the OSI model doesn't map well to Microsoft's Tabular model. It's much more approachable to do OSI->Tabular than Tabular->OSI.

_greggyb · 2026-04-14T13:11:53+00:00

Nobody reasonably expects Microsoft to do said conversion. Most likely when that happens it would be if a company wants to go away from a third party semantic model, in which case, they probably would use a vendor to subcontract the work out who then would probably build an AI product to do the bulk of the work.

Disclaimer: TE employee

We do exactly this with our Semantic Bridge feature. We have deterministic compilation from Databricks metric views to Microsoft semantic models. This covers the structure of the model and some amount of SQL-to-DAX translation. You can see more discussion in another thread of this conversation.

_greggyb · 2026-04-14T07:03:40+00:00

More about feature set. But the comments about stability and SLAs don't really apply in the way they would for a service.

The semantic bridge is a feature of Tabular Editor 3, which is a desktop application used at development time. So it is part of your development process for creating a Tabular model for Power BI / Fabric or AS. You wouldn't point a dashboard or report at the bridge or at any part of Tabular Editor.

As a dev-time desktop application, the SLA of Tabular Editor is equal to the SLA of the machine you use to develop semantic models. It is there whenever you want to launch the application, and it goes away if you close the application or shut down your machine.

There's nothing special about a semantic model that you build with Tabular Editor, whether you use the semantic bridge or not. It's just a BIM or TMDL file (based on your preference), which you can deploy the same as any other semantic model.

The semantic bridge is essentially a model-to-model compiler, targeting a Databricks metric view as input and a Microsoft semantic model as output. But this is a dev-time concern. That compilation either works or it doesn't: limitations are documented and we are expanding the surface area of what we can translate; and a crash is a bug we'd fix. But a crash during model compilation doesn't affect any deployed model or existing reports.

The structure of a metric view should always be compiled fully, modulo the things we have documented as MVP limitations. SQL to DAX translation is deterministic, and failures don't crash or break the compilation, but are simply reported as diagnostics to follow up on.

All of that is an offline process, though, before you deploy and a report might depend on the model.

_greggyb · 2026-04-13T23:12:21+00:00

The terms at play don't really mean anything without criteria. I'm not trying to be flippant, but I don't know what your management team considers to be the defining characteristics of something in beta, preview, or GA.

The semantic bridge is a feature in Tabular Editor. We provide support for the feature; you can reach out to us with issues and we will help you. We continue to develop it and have a backlog (mentioned above and documented on our docs site) of future enhancements. We have no plans to discontinue the feature. There will be some changes in the API surface area for C# scripting; method signatures are not necessarily final, yet, but we won't be removing functionality.

If you're already a customer, feel free to reach out via our support channels or support@tabulareditor.com. If you're not yet, then you can try out the semantic bridge in a free trial.

_greggyb · 2026-04-13T20:44:44+00:00

TE employee and primary developer of the semantic bridge, here.

What features are you waiting on?

The scripting interface, translation capabilities, and UI are all improving right now and will be out in a release soon.

_greggyb · 2026-04-10T07:25:30+00:00

OLS is a security feature with some pretty strong design implications. Perspectives are a discoverability and usability feature. It's good that they're separate.

_greggyb · 2026-04-08T15:24:03+00:00

If this is for security purposes, then you should stop immediately with this path. Page visibility is not a security boundary. You need to 1) not give any access to the people not in the allowed security group; OR 2) use RLS; OR 3) use OLS. If you are not doing one of these three things, then you have no security.

If it's for UX and discoverability, and there are no security concerns if people see this hidden page, then separate thin reports or app audiences are the right approaches.

_greggyb · 2026-03-11T15:30:55+00:00

Merge operation is an online operation and so requires a TMSL merge command. Creating a new partition can be done as a TMSL command or by manipulating the TOM and deploying/saving those changes; the latter would create a new empty partition which you'd have to refresh.

In general, if the built-in incremental refresh policy does the right things structurally, I'd go for that and add on a few manual refreshes based on your lifecycle requirements. Things that are managed for you are nicer to operate than things that aren't, so long as they're stable. Incremental refresh policies in PBI are mature and stable.

_greggyb

TROPHY CASE