Business Dashboard Specification: Metrics, Permissions and Acceptance Tests

A useful dashboard helps a named person make a specific decision. Write that decision first: which overdue orders need attention today, which invoices require reconciliation, or which support queue needs an extra person. If a metric does not affect a decision, it may belong in a periodic report rather than the main screen.

For every tile, record the owner, definition, data source, refresh interval and action. “Sales” is not a complete definition. Specify whether the number means orders placed, payments received or invoices issued, and how refunds, tax, cancellations and timezone boundaries are treated.

Suppose a sample day contains ten orders worth AED 100 each and one order is cancelled. A dashboard showing AED 1,000 of orders created and another showing AED 900 of active order value may both match their definitions. The problem is calling both numbers revenue without explaining the difference.

Use this example as a test fixture, not a claimed client result. Add a refund on a later day and a payment just before midnight. Confirm which period each event belongs to. Agree the accounting interpretation with the responsible business person before implementing a finance total.

For each metric, keep a compact specification: label, purpose, formula, included statuses, excluded statuses, timezone, currency, source table or API, owner and known limitations. Link that definition from the dashboard or make it available in the handover.

A filter must apply consistently. If a branch filter changes the chart but not its total, the display invites the wrong decision. Test the same period and filters against an independently prepared sample report. Preserve the record identifiers used in the comparison so discrepancies can be investigated.

Define who can see company-wide, branch-level and personal data. Apply that scope in the backend query or policy, then test it through direct requests. Hiding a column in the interface does not protect data already returned by the API.

Exports need the same permissions and filters as the screen. Check Arabic text, date formatting, long identifiers and spreadsheet formula injection when exporting untrusted text. Decide whether a large export should run in a queue and how long its download remains available.

Display the last successful refresh when data comes from another system. An old total with no warning looks authoritative. If an integration fails, keep the failure visible and explain whether the displayed value is stale, partial or unavailable.

For larger histories, evaluate summary tables or scheduled aggregates against the actual query pattern. Do not assume every dashboard needs real-time processing. A five-minute update may be suitable for one operational decision and unacceptable for another; the business requirement should decide.

Have the owner reproduce three important decisions using the dashboard. Test empty periods, partial imports, duplicate records, corrected transactions and users with different permissions. Compare chart totals, detail rows and exported totals using the same filters.

Document backups, restore responsibility, access removal and the procedure for correcting source data. Measure any claimed time saving with a baseline and the same tasks after launch. Without those measurements, describe the delivered functions rather than promising a fixed number of hours saved every week.