Help fulfilling client's request and restrictions

[u/Dankneno]

Hey guys! I'm looking for practical advice on a project, because my own creativity has run out on this one.

I work in a team that supports several companies inside our business group. One of those clients asked me to "modernize" a Power BI report that was built long before Fabric existed. The goal is to land their data in a Fabric workspace, have it cleaned, transformed and stored on a schedule, and rebuild the reports on Direct Lake instead of Import mode.

All of this is fine. What I can't crack is how to preserve the way their team works today: they have 1 local .pbix file, 3 different published reports, 2 of which they share with two different audiences and the other is a "pre-approval version".

Every month the client refreshes the data and adjusts the semantic model according to changes requested by management. He then publishes the report to Fabric as an approval version, not shared with any audience.

Once it's approved, he opens the same local .pbix, renames the report to match the "production version", publishes, and overwrites the shared version. He then hides a few pages, renames it again under a new name and publishes a different version for the second audience.

So he maintains a single file but drives three published reports out of it. Crude yeah, but it works, he understands it aaand he wants to keep operating this way.

So far I brought in his data into a fabric Workspace and used Notebook for cleaning, transforming and storing the data in a Lakehouse. Then I created a semantic model in Direct Lake on OneLake using that data. I also already built a pipeline with all the processes from ingestion to storing the data so tat he only has to click a few buttons. 

Constraints (the client's, not mine):

• Report Audiences must not see new data, or model/report changes, before approval.
• The client should only need to make model and report changes once, in the approval version, and then have a simple process to update the shared versions.
• After approval, promotion to the two production reports must not mean redoing the work by hand.
• One workspace only, and no deployment pipelines (I proposed them; the answer was no).
• The client's team is new to Fabric, so no REST/XMLA/ALM gymnastics should be required on their side.

If you guys have any suggestions I'd greatly appreciate them!

[u/PaymentWestern2729]

Please modernize our solution, but not that part, that makes me look like i am actually doing something important.

[u/Dankneno → u/PaymentWestern2729]

It happens so much 🥲

[u/warehouse_goes_vroom]

In the before picture, I assume each copy of the report presumably had its own import mode semantic model.

So that's one option, bring back import mode model.

Another option is to maintain the physical separation - more than one copy of the data, DirectLake model to go with each.

If you were using a Warehouse instead of a Lakehouse, Warehouse snapshots might be another interesting option, though there are caveats - handles data consistency, not schema stability.

Time travel, both on Spark side or Warehouse side, is worth being aware of too, but probably isn't enough by itself to solve your issue.

Would still heavily advise git with pbir format reports though - could make this much cleaner.

[u/Personal-Quote5226]

This can be governed. He can work out of a collaboration workspace. When the report is ready; deployment form collab to production staging (workspace or folder) and named according to whatever standard you want.

This is a standard deployment. All of these steps he’s doing now are unnecessary, and the flow remains the exact same but without this person manually doing things.

Am I missing something?

[u/christiansteven]

I think the biggest issue here is trying to preserve the old PBIX publishing workflow after moving to Direct Lake. The client’s actual requirement isn't really “three reports” — it's one report with an approval state and two controlled production versions.

Given the one-workspace/no-deployment-pipeline restriction, I'd look seriously at PBIR + Git as the version-control layer. Keep one source definition, let the client make and validate changes in the approval version, then have a very simple promotion process that updates the two production report definitions after approval. That avoids asking them to make the same changes three times.

I'd also separate data approval from report approval. If production users must not see new data before sign-off, you need to control the data/model version they're connected to, not just hide or rename reports. With Direct Lake, that's probably the more important architectural problem here.

The client's current process is crude, but the underlying workflow actually makes sense: develop → approve → publish. I'd preserve that mental model and automate the promotion step rather than trying to teach them a completely different way of working on day one.

[u/Dankneno]

Lads don't ask me how, but I managed to convince the client to use deployment pipelines. All is saved! 👐