I have been having interesting discussions with colleges around good practices on Power BI projects.  There seems to be something we all agreed on, it’s that Power BI models can be really messy, hard to maintain but can be mitigated with a few extra implementation steps. Creating a good model can often become the first step towards an excellent project or a complicated project that becomes hard to support and maintain. Especially if you work on a company that often finds itself ‘smooching’ data together from different sources to create reporting, then this can be very helpful to you. We, as BI developers, need to make sure the Power BI models are as reusable and easy to maintain as possible. Not only for performance but for future rework or updates. To make life easier for ourselves, we have set up a few standards for Power BI reporting structure, I will share those with you today because I believe it makes a lot of difference in the long run. Using this framework can be the difference between reusing some of the hard work you implemented or having to start from scratch again. This blog post will not cover how to create the facts and dimensions in the model. We are starting from the assumption that you know how to do that, these tips/rules are more orientated to improvements on the process for a better reporting platform. So, let’s start with rule number 1: The model and the report(s) are created in different Power BI desktop files. The reasoning behind this is that if you have the model published as a separate PBIX file (dataset) to the Power BI Service, then you can ‘hook’ as many reports as you need to use the same dataset. Let’s analyse this with an example: When we have to develop a project that requires reporting in different categories. We can create one dataset and multiple reports, one per category, all using the same published dataset. The great use case for this one is if we have a change in the definition of measures. Having one dataset and multiple reports will handle this issue very well. As soon as a change is made to the dataset file and published, then all the reports will get the change by just refreshing it. Rule number 2: Split reports into smaller pieces, if possible. Usually, report requirements include a few different categories (e.g. client, account, product, invoice, etc.), when we design one report that contains everything makes it more difficult to customise styles and filters. By creating a report per category this allows designing the layout, filters and granularity in the report in a way that will be more effective for the end-user. Rules number 3: Date tables are a must! Power BI identifies all the dates in your model and creates tables for each one of them behind the scenes to add date hierarchies and other metadata that can be used in DAX. As your model grows, these tables grow as well, potentially creating performance issues in the future. Creating your own table and creating relationships between that table and the dates in your model minimises the amount of data and tables built in the background. This will make your model run faster and makes it more scalable. Rules number 4: Cover page is always useful. Creating a cover page that contains a brief description of the report, any important concepts that need to be acknowledged for the report. For instance, the environment the report is running on, the last refreshed date and the next refresh date. Having these information displayed can make a lot of a difference to end-users. Also, adds a nice initial page to see when you open to report.   I hope these tips are useful for you, and if you have any other ones, leave them in the comments below.