Microsoft Power BI Best Practices

I've been creating Power BI dashboards and wanted to share some of the best practices I've learned.

• Make datasets user friendly. Rename tables and columns to descriptive terms, remove unnecessary columns, hide columns not needed by users (such as index or surrogate keys) and make sure data types and formats are correctly assigned. Remember, we're using this tool to put business intelligence into the hands of analysts and power users so usability must be a top consideration.
• Reduce data model sources and columns/rows to only what data is necessary (for performance and too simplify data selection for users).
  • Use the DateTime filter when a dataset includes data for multiple years. In Query view, you can apply DateTime filter options (This month, This quarter, etc.) or select Date Filters > Custom Filter and apply Boolean logic.
  • On Dashboards, apply one or both types of report filters. Visualization filters apply to individual charts or visualizations. View filters (aka page level filters) apply to entire page.
• Data types should be specified in order to improve performance and usability. For example, names should be strings, revenue should be a decimal, headcount should be an integer and close date should be a date. Note that if Power BI detects a null value or error in a column record, it will not specify the correct data type for the entire column so you will need to manually make these corrections.
• When merging tables and applying primary/foreign key relationships, if possible, use single column integer keys for maximum performance. This could include CustomerID, ContactID, ItemID, OpportunityID, etc. or you may use or create a surrogate key for this purpose. This method will deliver a big performance improvement. If for some reason you don't want to use an integer key, date is the next best option.
• Try to always use a separate date table. This will likely better normalize the data and there are several (period-based) DAX formulas (TOTALQTD, TOTALYTD) which require a date table. CRM schemas generally have one date table while ERP schemas often have many (i.e. for order date, ship date, invoice date, payment date, etc.)
• Data models should be filtered and normalized. This is particularly important if datasets are sourced from high data volume repositories such as enterprise data warehouses.
• Normalize your data when building the dataset using the Designer Relationships view. Normalization separates unrelated table data (i.e. no need for Case and Campaign data to be in same table) and parses grouped data in a single column to multiple columns (date/time, names and addresses are prime examples) in order to optimize query performance.
• Use a star schema when designating table relationships. This consists of a central fact table (i.e. transactions) encircled by dimension (i.e. master) tables. A common CRM example is an opportunities fact table surrounded by the account, contact, salesperson (user), activity and campaign tables. Fact tables will normally include many transactions and have a date/time component. Dimension tables normally possess fewer rows and contain (generally descriptive) attributes about the transactions. When interrogating data, the dimensions are normally the row and column headers while the fact elements are the values in the body cells. Star schemas improve query and aggregation performance.