Power BI Self-Service and Data Modeling Questions – Seeking Your Insights

Hi ricardo_martins ,

1. Helper tables for filtering scenarios
Yes, your understanding is correct. In Power BI, disconnected helper tables are sometimes used when you need special filtering logic that cannot be handled with direct relationships. The example you gave about selecting a month in a slicer but showing the last X months in a visual is a common case.
You do not always need a separate helper table for every single scenario. For date-based cases, you can usually handle this with your main date table and some smart DAX logic. For non-date fields, instead of multiple helper tables, you can use one parameter table that drives a SWITCH function in your measure. This keeps your model cleaner and avoids having too many similar tables.
The trade-off is that users need to know this slicer is special and works only with certain measures. That comes down to user training.

2. Calculation groups for time-based analysis
Calculation groups are the best way to handle common time intelligence logic such as last three months, last four quarters, or year to date.
If you have multiple date fields such as invoice date, delivery date, and shipping date, the most common practice is to have one calendar table with multiple inactive relationships and then use USERELATIONSHIP in your measures or calculation group logic. This makes the model simpler but adds some complexity to the DAX.
If you want simpler DAX and less confusion for end users, you can use separate calendar tables for each date type. This makes the model larger but more straightforward for users who may not be comfortable with USERELATIONSHIP.

3. Active and inactive relationships for dimensions
Yes, the usual approach for scenarios like sold-to versus delivered-to is to have one customer table with inactive relationships and then activate the relevant one in a measure using USERELATIONSHIP.
You will typically need separate measures for each relationship unless you use a disconnected selector table or a calculation group to dynamically switch between them. This can reduce the number of measures you have to maintain.

4. User created reports and version control
You are correct that when a developer republishes a report, it overwrites user-created pages.
The best practice is to separate the dataset from the reports. Publish one dataset that contains your model and measures. Then have one official report connected to that dataset, and let users build their own reports in the Power BI Service using the same dataset.
For your three-layer idea, you would indeed need three separate reports pointing to the same dataset. One would be the official developer report, one would be the personal report for individual users, and one would be the community report for shared content. Another option is to create a Power BI App that contains multiple reports, but behind the scenes it is still multiple files.

5. Other self-service and data modeling challenges
There are a few more to keep in mind.
Security can get tricky when you have row level security and many self-service reports. You need to decide whether to control security centrally or let dataset owners manage it.
Measure explosion is a real risk when you try to pre-build every possible variation of a measure. Calculation groups and measure branching help keep this under control.
Naming conventions are critical. A technically perfect model still fails if users cannot tell which fields to use with which measures.

Bonus Tip: Do not underestimate the need for user training. Even a well-designed self-service environment will fail without clear guidance on how to use it.

I hope this helps