Why does Power BI have features like Auto Date/Time and Implicit Measures enabled by default if the best practice is NOT to use them?

It seems short-sighted, inefficient, and counter-productive to teach new users bad habits and anti-patterns, only to go back and re-educate them with best practices at some later date (if ever). Not only do these users have to un-learn what they learned before (which is difficult enough on its own), but they also have to go back and refactor all the reports and datasets they initially built poorly, just because they didn't know any better at the time, and no one told them there was a better way to do it!

Instead of catering exclusively to the lowest common denominator by default, why not incorporate some basic "Best Practices Workflows" in the Power BI report authoring UI that teach new users how to follow best practices with a hands-on approach? For example:

  • Auto Date/Time:
  • Whenever the user tries to add a Date/Time column to a visual, why not have Power BI open a dialog that walks the user through creating a Date Dimension (either in DAX or in Power Query) and connecting it to the relevant Fact Table(s) in the model?
  • This would help new users learn the basics of Star Schema Data Modeling and Time Intelligence right from the beginning.
  • Implicit Measures:
  • Whenever a user tries to add a column to the values part of a visual, why not have have Power BI launch the New Quick Measure dialog, and then walk them through creating the measure they need?
  • Most new Power BI users are coming from Excel, and are likely at least somewhat familiar with writing simple formulas, so this would be a natural progression for them, and would help ease them into writing Explicit Measures in DAX.
Under Review

Thanks for the suggestions, we are already looking at what we can do to improve auto date/time. However, please consider the "number of clicks to success" - auto date time and implicit measures, while not best practices allow new users to get to success quickly without the product getting in the way. The suggestions you're making, while they are great and make a lot of sense after you know what you're doing, get in the way and do increase the number of clicks to success, hence increase the number of people dropping off and giving up. It's a balance we have to find. Right now, my money is on making auto date time smarter so using it is not "as bad". For implicit measures, I personally don't feel so strongly as they don't result in the issues that auto date/time covers, but I'll think about it some more. Thanks for the input, it's been heard loud and clear!



9/10 times when I add a field column to a table, I didn't want the auto-measure anyway and have to go turn it off. Having a dialogue pop up for each column would be excessive. Maybe an icon could appear with a dropdown of the common measures so:

  • No measure required - Zero clicks
  • Suggested measure - One click
  • Common measures - One click to open dropdown and a second to select
  • Uncommon measures - Two to open the create measure dialogue, plus several more to make it

1/10 times is still a lot, though. My reports already are quite full of calculated columns and measures and managing them is already a headache. If every implicit measure became an explicit one, this would make the problem even worse. If the summary type was changed, or the column removed, this would result in a steady growth in unused measures. I'd suggest that before making explicit measures required, there would need to be better tracking available of which measures are and are not in use.

What happens if the same field is added to two tables? Does this create two measures?

It's also good practice to have a separate model, and then reports that feed off this single model. Having required explicit measures at visual design time would create the measures in the dependent reports, when they may be better off in the main model. It doesn't seem possible to handle doing this automatically. While I think it would be useful to have a way to "push" measures, etc. between parent and child parts of a lineage, it would probably be too much to make that a pre-requisite of this request.


I love these ideas of auto-educating the users! This will surely help in getting best practices adopted better/faster. You could link to MS docs (or SQLBI) articles to explain the concepts.