Before Building a Dashboard, Fix the Data Flow

Dashboards are often one of the first things discussed when a new application is being planned. People want to see transaction totals, unfinished work, low stock, or a chart of monthly activity. Those requests are reasonable. The problem is that a polished screen cannot fix data that was recorded incorrectly in the first place.

In several projects I have worked on, the difficult part happens before a number ever reaches the dashboard. One person records the data and another reviews it. A document cannot be shown until it has been approved. A transaction changes stock. An event sent by a device still needs a staff member to review it. When this sequence is unclear, the dashboard simply presents the confusion in a more attractive format.

Start with the decision, not the chart

Before choosing statistic cards or chart types, I try to understand the decision the page needs to support. The useful question is: after looking at this dashboard, what should the person do next?

• Does an administrator need to review a new payment?
• Does a staff member need to follow up on a missed appointment?
• Is there stock that needs to be replenished?
• Does management need to compare activity across a specific period?

The answers determine which data belongs on the page. An all-time total may look impressive without helping anyone today. A list of five overdue tasks is often more useful because someone can act on it immediately.

Decide who records the data and who reviews it

Operational data rarely stops with the person who first enters it. A customer uploads payment evidence and an administrator verifies it. A health document is recorded by staff, while access for a parent or guardian remains restricted. A first aid box sends an opening event, then a staff member reviews the visual evidence and records which items were removed.

Each important record therefore needs a clear owner. I usually write down three things: who creates it, who may change it, and who may only view it. This small exercise helps shape access control and prevents records from changing without a path that can be traced later.

Give each status a precise meaning

The word pending is often asked to cover too many situations. “Waiting for evidence,” “waiting for review,” and “reviewed but needs correction” all require different actions. If they share one status, users have to open every record just to find out what is actually happening.

A useful status describes the record’s position in the process. Each change should also record when it happened and, where relevant, who made it. The “7 items to review” shown on a dashboard then has a clear source and can lead the user back to the original records.

Connect the stages instead of copying data

A common source of trouble is copying the same information into several places. Booking details are copied into a work order. A user’s identity is typed again on a transaction. A stock value is stored separately without a history of its changes. This may feel quick early on, but correcting one copy can easily leave an older value elsewhere.

I prefer to keep the records connected. A work order points to the booking that created it. A stock transaction refers to the related event or request. A visit remains attached to the same child profile. When a value needs to be summarized for performance, it should still be possible to explain where that calculation came from.

For operations that may be sent more than once, such as requests from a mobile application or a connected device, I also check whether idempotency is needed. The practical goal is simple: sending the same request again must not create a second transaction or adjust stock twice.

Keep detailed evidence separate from the summary

Field photographs, health documents, payment evidence, and device recordings may all matter, but they do not belong directly on a dashboard. A summary page only needs to show that evidence exists, its review state, and who needs to act. The original files can remain in an area with the appropriate access rules.

This separation makes the dashboard easier to scan and reduces the chance of sensitive information being shown to the wrong person. Users can move from the summary to a detailed record when they need it instead of receiving everything at once.

Choose the numbers and charts last

Once the process, statuses, and responsibilities are stable, the visual choices become easier. Dashboard information can usually be split into two groups: things that require action now and summaries that help people recognize a pattern.

The first group might include payments awaiting verification, critical stock, missed schedules, or device events that have not been reviewed. The second could include transaction trends, service totals by period, or incidents distributed across a map. Both are useful, but they do not always deserve the same amount of space.

A checklist before drawing the dashboard

1. Write down the decisions or actions the dashboard should support.
2. Identify the source of every number and the person responsible for that data.
3. Separate statuses that require different actions.
4. Connect records across the process instead of copying them without a reason.
5. Decide which information may be summarized and which evidence must stay private.
6. Check that a user can move from a summary number back to its source records.

I usually wait until those six questions have clear enough answers before drawing the dashboard. The result may not be packed with charts, but every element has a reason to be there. For operational software, that matters more than making the first screen look busy.