Before the dashboard: can you trust the data?

Start with the question your business needs to answer

A dashboard can make a number easy to see while leaving its meaning unclear. Before choosing charts, write the question behind the report. Are you deciding which requests need attention, whether stock needs replenishing, or how much work remains unfinished? Each question requires a different set of records and a different definition of complete information.

Choose one question for your first review. Identify where the records come from, who creates them and who can explain exceptions. Keep a copy of the original material so that a correction can be checked against its source.

Agree on what one row represents

A row might describe an order, an item within that order or a change in its status. Those are different things to count. Write the meaning in everyday language and confirm it with someone who uses the information. Also establish which date determines the reporting period and which status makes a record eligible.

Pay attention to units. A box and an individual item need an agreed relationship. Amounts in different currencies need an explicit basis before they can be compared. A blank field needs a reason: it may mean unknown, not applicable or still pending. Replacing every blank with zero changes that meaning.

Review a few essentials before building visuals

You can begin this review in a spreadsheet. The important part is agreeing what to do when a check fails. A record should remain traceable while someone investigates it. Removing an unusual value merely because it looks inconvenient can erase the very issue the report should reveal.

Microsoft documents quality, distribution and profile views in Power Query. Its profiling initially covers the first 1,000 rows unless you select the whole dataset. Check that scope before treating the preview as a review of all your records.

• Confirm that required fields contain the information the decision needs.
• Check that dates, quantities and categories have a consistent meaning.
• Investigate repeated identifiers before deciding whether records are duplicates.
• Compare the reporting period and included statuses across source files.
• Record unresolved exceptions, their owner and the next review date.

A synthetic example: why the order count changed

Imagine a fictional business combining two order lists. One contains a row for each order; the other contains a row for each product ordered. Adding both row counts produces a misleading total, even though each file is internally correct.

The useful conversation is about the unit being counted. The team agrees that its overview will count orders and that product detail will support a separate question. It documents which records belong in each view. This invented example illustrates a definition problem; it does not represent a client or a measured business result.

Make quality part of the routine

Once the first version is understandable, give the review a place in normal operations. Display the period covered and the latest successful update. If a source is missing, explain the gap where people read the report. Assign someone who can confirm whether the information is suitable for the decision at hand.

Keep a short change record when definitions or source fields change. Revisit earlier comparisons if their meaning has changed. The practical outcome is a report whose assumptions people can explain, with a manageable list of open questions. That is a sound starting point for discussing a dashboard with your team.