Day 29: Power BI Best Practices

Tables: PascalCase without spaces — SalesData, DimProduct, DimCustomer, DimDate (Dim prefix for dimensions, Fact prefix for fact tables). Columns: Title Case with spaces — Product Category, Order Date, Customer Name. Measures: Sentence case starting with a capital — Total Revenue, Revenue YoY Growth %, Active Customers. Prefix measures with their type for sorting in the field list — [_Total Revenue], [_YoY%] (underscore prefix groups them). Do NOT use: abbreviations that are unclear (RevCust instead of Revenue per Customer), all caps, generic names (Column1, Measure1). Consistent naming makes model maintenance much easier.

Pre-sharing checklist: (1) Validate numbers — compare key metrics against a known-correct source (previous report, SQL query). (2) Test all slicers — confirm they filter correctly and reset as expected. (3) Test drill-through — confirm the right data appears on detail pages. (4) Test on different screen sizes — check mobile layout if users will view on phones. (5) Remove any test measures or unused queries. (6) Confirm data refresh is working in Service (if applicable). (7) Apply RLS if the report contains sensitive data. (8) Write a brief description of what the report shows in the report's description field in Service.

Documentation approach: (1) Model description page — a hidden report page with a screenshot of the model diagram, table descriptions, and relationship notes. (2) Measure descriptions — right-click each measure → Properties → enter a description. These descriptions appear in tooltips in the field pane and in Power BI Service. (3) Query comments — add descriptive step names in Power Query (rename "Changed Type1" to "Cast Revenue and Date to correct types"). (4) An external document (Confluence, SharePoint) listing: data sources, refresh schedule, business definitions of each measure, known data quality issues, and contact person for questions.

Average: builds visuals quickly without thinking about the data model, writes complex DAX without understanding filter context, creates reports that look good but contain calculation errors that nobody notices, shares reports without validating numbers. Good: designs the data model correctly before building any visuals, writes DAX with explicit understanding of how filter context changes at each step, validates every metric against a known source before sharing, considers the end user's workflow and optimises for their questions (not "I added every possible chart"), monitors report performance and keeps pages fast, documents their work so others can maintain it. The difference is discipline, not just technical skill.

Professional response: First, do not immediately defend your numbers or accept theirs. Step 1: document both numbers and the context (filter settings, time period, what measure was used). Step 2: trace back to the source — run the equivalent SQL query directly on the database and check against both. Step 3: investigate likely causes — different date range interpretation, different handling of returns/cancellations, different customer segments being included. Step 4: once the discrepancy is identified, document the correct business definition in writing and get explicit agreement. Step 5: update the measure definition and add a description explaining what is included/excluded. Step 6: revalidate after the fix.