Building a Sales Dashboard

Before opening Power BI Desktop, sit with the actual stakeholders — a VP of Sales, regional managers — and pin down which 4-6 KPIs matter most: typically total revenue, revenue growth versus prior period, average deal size, win rate, and pipeline value. Sketch the page layout on paper or in Figma first, deciding what a viewer needs to see in the first three seconds (usually big-number cards for the top KPIs) versus what belongs on a drill-through page (deal-level detail, rep-level breakdowns). Skipping this step is the single most common reason sales dashboards end up cluttered and unused.

A solid sales dashboard model centers on a Fact_Sales table (one row per order line: date, product, customer, salesperson, quantity, amount) connected to Dim_Date, Dim_Product, Dim_Customer, and Dim_Salesperson dimensions in a star schema. Bring in a Fact_Target table at the salesperson/month grain if the business tracks quotas, and relate it through Dim_Date and Dim_Salesperson so actual-vs-target comparisons work naturally. Keep transactional detail (individual line items) in the fact table but push descriptive attributes like product category, region, and customer segment into the dimension tables so slicers stay fast and the model stays clean.

Open the page with card visuals for Total Sales, YoY Growth %, and Attainment %, placed top-left where eyes land first, then add a line chart of sales trend by month to show trajectory, a matrix broken down by region and product category for detail, and a bar chart ranking top salespeople. Add slicers for Date range, Region, and Product Category near the top or in a consistent left rail, and sync slicers across pages using Sync Slicers so filtering feels consistent as users navigate. Conditional formatting on the matrix (color scale on Attainment %) turns a wall of numbers into an instantly scannable heat map.

Publish the .pbix to a dedicated Power BI Service workspace (e.g., 'Sales Analytics'), then package the report into a Power BI App for distribution to end users rather than sharing the raw workspace, which keeps the editing environment separate from the consumption experience. If different regional managers should only see their own region's numbers, implement Row-Level Security (RLS) by creating roles in Power BI Desktop with DAX filter expressions (e.g., [Region] = USERPRINCIPALNAME()) and mapping users to roles in the Service, so one dataset securely serves every manager their own slice.