Dashboards and reporting

See what is happening. Know what needs attention.

The numbers often exist. People still spend the week copying them into a spreadsheet, reconciling two exports, or asking someone else what the current picture is. PrimeLabs builds the view that puts the right figures in front of the people who decide, with the record behind the number and a way to act on it.

Start with the decision, not the chart

The useful first questions are plain. What decision does this person need to make? What needs attention? What changed? What is behind the number? What action follows?

A report should answer one of those. An operational dashboard should show the current state. A historical report should show change over time. Exceptions usually matter more than the grand total. A KPI without a way into the records creates a second round of questions. Different people can have different views of the same underlying data: an executive, a coordinator, a finance clerk, a service desk, or a customer who may see only their own account.

The hard part is often the data, not the drawing

A reporting view may combine the application database, a CRM, accounting, payments, an operational system, an API, an upload, event history, or the state of a workflow. Sometimes the hard part is not drawing the dashboard. It is reliably getting the right data into one place. That work is API integration, and it depends on each source system’s interface, permissions, limits and data model. Naming a source here is not a claim that it is already connected.

A dashboard does not repair inconsistent source data. Trust comes from ownership, definitions, timestamps, the system a figure came from, and the calculation rule. If two products can both change the same total, the screen will be argued with. The view should say which definition it used.

Live is a requirement, not a default

Not every board needs a stream. An event can refresh a queue when a request changes state. A near-real-time read suits a desk that is working the queue now. A schedule suits a morning snapshot. A person can refresh the record they have open. A daily close suits the monthly comparison.

The right freshness is the one the decision needs. Polling a ledger every second does not make yesterday’s invoices more useful, and it spends the provider’s rate limit.

From the total to the record

A useful path is summary, then segment, then the record, then the event or action underneath it. On the example board, 17 at risk becomes a reason split, then a request such as SR-4821, then the supplier wait that made it late. A manager who cannot open the case will ask someone else to do it, which is the problem the screen was meant to remove.

The same records can be cut for a role without copying the database. An executive may see trends and exceptions. Operations may see the queue, the workload and the failures. Finance may see transactions, reconciliation and ageing. A service team may see requests, response time and account state. An external stakeholder may see only the authorised records. A build does not need every one of those views. It needs the ones a real person will open.

That operations view is often one surface inside an internal business application, not a separate product beside it. A customer portal may expose a much smaller report to the account that owns the records, and nothing else. A SaaS product often keeps both: usage for the workspace, and the operator’s view of tenants, plans and failures. A knowledge screen may help someone find the record behind a figure. The figure itself stays a calculation in the report. The retrieval pattern is AI knowledge systems.

Exceptions before totals

The cases that need a person are the ones worth the top of the screen: overdue work, failures, an SLA at risk, an unusual change, missing data, an item waiting for approval, a record that needs investigation. A healthy total can hide all of those. The example holds the 17 at-risk requests above the month’s 1,248 completions for that reason.

Analytics calculates. A model may explain.

Totals, percentages, ageing, SLA, variance and money are ordinary calculations. They stay in code, on the records, with a definition someone can read. A model does not replace that arithmetic and it does not invent a KPI.

Where a model helps is afterwards. It can summarise what changed, explain a spike in the words a manager will actually read, point at an unusual pattern, draft commentary for a person to edit, help someone ask a question of the dataset already on screen, or suggest records worth opening. The answer on this page cites the medians and the equipment waits. It does not produce a new median. How that boundary is drawn more generally is AI application development.

A number is still access to a record

Role decides which measures appear. Row and account decide which records a drill-down may open. Financial and operational totals are sensitive even when they are aggregates. A second organisation’s figures are not a filter away. Export is its own permission, and a useful audit trail can record who exported what. The web application around the board is what enforces that.

Scale is the same idea in the other direction. Precompute an aggregate when the question is asked every morning. Paginate and filter the records underneath it. Do not ship a year of events to the browser to draw one chart. A snapshot can be the report. None of that is a promise about a particular speed. It is how the view stays the size of the decision.

Start from the question people keep asking

A useful first note names who asks, what they decide, which figure they currently rebuild, where that figure comes from, and what they open next. There is no account on this website.

Discuss a reporting view

Straight answers