TL;DR: To build a production dashboard on Dynamics 365 data that people actually use, start from the decisions it must support, not from the tables. Define each KPI in writing, standardize it across plants, model the data at an explicit grain, validate against what supervisors see on the floor, and only then build visuals. The ten steps below take you from first question to a dashboard that survives user testing.
Most failed manufacturing dashboards don't fail on the tech. They fail in the first review, when a production supervisor looks at the scrap chart and says, "That's not how we count scrap." This framework is built to avoid that moment.
The framework
Step 1: Define the manufacturing questions
Write down five to ten questions the dashboard must answer, with the person who asks each one. For example:
• Supervisor: Which of today's jobs are behind, and on which resource?
• Plant manager: Are we producing to plan this week?
• CI lead: Which operations generate the most defects?
If a proposed visual doesn't answer a listed question, it doesn't ship in version one.
Step 2: Identify the relevant Dynamics 365 data
Map each question to the source data in Dynamics 365 Supply Chain Management. Typical areas include production orders and batch orders, routes and operations, resources and resource groups, route feedback (good and defective quantities, time), inventory transactions, quality orders and nonconformances, and production cost calculations.
Check what your implementation actually uses. A site running kanban has different data from one running production orders. A site without quality management enabled won't have nonconformance records.
For extraction, Microsoft documents Azure Synapse Link for Dataverse and Link to Microsoft Fabric as ways to replicate finance and operations tables.
Step 3: Define manufacturing KPIs
For each question, name the KPI that answers it. Keep the list short. Five well-defined KPIs beat twenty ambiguous ones.
Step 4: Standardize metric definitions
This is where the "that's not how we count scrap" problem gets solved. For each KPI, document:
• Numerator and denominator
• Which date drives it (requirement date, scheduled end, reported-as-finished date, ended date)
• Exclusions (rework orders, test runs, specific order types)
• Owner who approves changes
Get sign-off from each plant before building. A useful reference: Microsoft's built-in Production performance content defines "in full" as good quantity greater than or equal to scheduled quantity. Decide whether you adopt that or change it, and write down why.
Step 5: Design the analytics model
Build facts at an explicit grain: one row per production order, one row per operation feedback transaction, one row per cost line. Conform shared dimensions (site, resource, product, date) so filters behave the same across every page.
Track history on attributes that change metrics, such as a resource moving to a new resource group.
If you'd rather not design every table from zero, some teams start from an enterprise analytics accelerator that ships a Dynamics 365 manufacturing data model and metric library, then adjust it to local definitions from Step 4. Building custom is equally valid when processes are unusual. Either way, Step 4 still applies.
Step 6: Validate data quality
Before any visuals, reconcile. Pick one plant and one week. Compare your model's totals against what supervisors and finance already trust. Automate checks for:
• Orders reported as finished but not ended
• Good plus defective quantity exceeding started quantity
• Feedback posted to resources outside the route
• Missing or zero time registrations
Differences are either data problems or definition problems. Both are cheaper to fix now.
Step 7: Build the dashboards
Design by role, not by data source. A supervisor view should show today and this shift. A plant manager view should show this week versus plan, with drill-through to resources. An executive view should compare plants on standardized KPIs.
Put the most-asked question in the top-left. Use consistent colors for status across all pages.
Step 8: Establish governance and access controls
Apply row-level security by site and legal entity. Publish the metric definitions from Step 4 alongside the dashboard, ideally one click from each visual. Route definition changes through the named owner.
Step 9: Test with manufacturing users
Sit with a supervisor during a real shift and watch them use it. Ask them to answer three of the Step 1 questions without help. Note where they hesitate or reach for a spreadsheet. This is the test that catches the scrap-definition problem if Step 4 missed it.
Step 10: Monitor and improve
Track which pages get used and which don't. Review KPI definitions quarterly. Retire visuals nobody opens. Add new questions only when someone owns them.
What a useful manufacturing dashboard can contain
The metrics below are common starting points. Treat this as a menu, not a checklist.
Important: not every metric here is a standard Dynamics 365 field. Availability depends on your Dynamics 365 configuration, the modules you've implemented, the data you actually capture, how much history you have, your business definitions, your integration architecture and your analytics model. Many of these are calculated measures, not stored values.
Production performance
• Planned production
• Actual production (good quantity reported as finished)
• Production variance against plan
• Throughput per resource or line
• Production order status mix
Downtime
• Downtime duration
• Downtime frequency
• Downtime by work center or operation
• Recurring downtime patterns
Machine-level downtime usually needs a source beyond ERP transactions, such as operator registrations, an MES, or Dynamics 365 Sensor Data Intelligence scenarios (documented as preview and requiring IoT sensors).
Scheduling
• Schedule adherence
• Production order delays
• Capacity utilization
• Bottleneck resources
Quality
• Scrap
• Defects (Microsoft's embedded content reports defect rate in parts per million)
• Quality exceptions and nonconformances
• Rework, where the available data supports it
Cost
• Production cost
• Cost variance (Dynamics 365 calculates production variances when orders reach Ended status)
• Material cost
• Resource and labor-related costs, where available
Inventory and materials
• Material availability for released orders
• Production-related shortages
• Inventory trends for critical components
• Material consumption versus BOM
A worked example: one KPI through the framework
Take schedule adherence.
- Question: Plant manager asks, "Are we finishing orders when customers need them?"
- Data: Production order requirement date and actual finish date.
- KPI: Percentage of orders finished on or before requirement date.
- Definition: Measured at order level, by reported-as-finished date, excluding rework orders. Early counts as adherent. Owner: plant operations lead.
- Model: Production order fact with both dates; date dimension joined on finish date.
- Validation: Compare last month's result against the planner's own list of late orders, and trace every difference to either a data issue or a definition issue.
- Dashboard: Trend line by week, split by site, drill-through to late orders.
Notice that Microsoft's embedded content treats early orders as a separate category from on-time. Your definition may differ. That's fine, as long as it's written down.
FAQ
Can I build this directly in Power BI on Dynamics 365 data?
For a single site with simple questions, yes. Once multiple plants, long history or cross-functional data are involved, a modeled layer between Dynamics 365 and Power BI is easier to govern.
How long should version one take?
Scope it to one plant and five KPIs. Timelines depend on data readiness more than on dashboard design.
Why do production dashboards show inconsistent numbers?
Usually because two dashboards filter on different dates or apply different exclusions. One counts by reported-as-finished date, another by ended date. Standardizing definitions in Step 4 and enforcing them in the model in Step 5 removes most of these conflicts.
