How we decide which metrics deserve a dashboard and which deserve a workflow
Some metrics are for observation. Others need ownership, thresholds, timing, and structured action. We decide explicitly which system shape each metric actually deserves.
Classify a metric by the decision expected when it changes.
If the value helps people understand performance, put it in reporting. If a particular condition should create owned work inside a useful window, build a workflow. Use both when aggregate context and individual intervention solve different parts of the problem.
Dashboard-first metrics support interpretation
A metric belongs in a dashboard when its primary value comes from comparison and context.
Typical examples include:
- revenue and margin trends
- customer concentration
- conversion by channel
- forecast versus actual
- service quality over time
- capacity and workload distribution
People need to select periods, segments, and comparisons before deciding what the movement means. The action may be strategic, periodic, or shared across a management process. A dashboard gives that judgment a stable surface.
The number can still be important. Importance doesn’t imply that every movement deserves a task.
Workflow-first metrics identify cases
A workflow needs a case, not merely a KPI.
“Revenue is down 8 percent” is a reporting observation. “Customer 1842 is down €40,000 against its seasonal baseline, the account owner is Jane, and intervention remains useful for seven days” is a candidate for work.
Workflow-worthy signals usually have:
- a stable business entity or event
- a condition specific enough to explain
- a named owner or routing rule
- a response window
- a finite set of useful actions
- deduplication and lifecycle semantics
- an acceptable false-positive and false-negative cost
The workflow should record what happened after detection. Otherwise the system can prove that it generated tasks while remaining ignorant about whether they helped.
Use the intervention test
For each proposed metric, ask:
- What should somebody do when it crosses the condition?
- Who is accountable for doing it?
- How quickly does action change the outcome?
- Can the system identify the affected case?
- What makes the case new, repeated, resolved, or expired?
- What does a wrong trigger cost?
- How will the response improve the rule?
If the answers remain vague, keep the metric in reporting. The dashboard gives the organization time to learn what the signal means before software begins distributing the ambiguity as work.
Thresholds don’t create actionability
Adding red, amber, and green bands to a metric doesn’t make it operational.
A threshold may be useful for visual scanning. To create workflow, it must correspond to a mechanism and response. Why does 10 percent matter? Does the absolute value matter too? How long must the condition persist? Should seasonality, data completeness, or account size alter it? When may the same case repeat?
Backtest the condition on historical data and review real examples with the people expected to act. Count volume by owner, segment, and day. A rule that creates fifty valid cases for one person isn’t operationally valid.
Match the trust requirement to the action
A display metric can tolerate known caveats because readers can apply judgment. A workflow signal needs stable grain, definition, update behavior, and source completeness.
The standard rises with consequence. An advisory review queue can accept more uncertainty than automatic account suspension or inventory movement. A KPI becomes trustworthy enough to automate around when the failure mode is understood and acceptable, not when its formula has survived one meeting.
Start with human review for a new signal. Capture structured outcomes. Tighten the rule before increasing automation.
Hybrid systems separate population from exception
Many useful metrics belong in both surfaces.
The dashboard shows the population: trend, distribution, segment, historical baseline, response volume, and outcome. The workflow carries individual exceptions requiring intervention.
For stock availability, the dashboard may show service level and risk by warehouse. The workflow assigns products projected to stock out before replenishment. For customer retention, the dashboard shows cohort movement while the workflow routes specific accounts whose decline is both material and actionable.
The same governed model can support both, but their serving contracts differ. The dashboard reads aggregates. The workflow needs stable entity identity, snapshots, ownership, and history.
Don’t turn every metric into a signal
Workflows consume scarce human attention. Every rule competes with existing work and trains recipients either to trust or ignore the system.
Keep a metric dashboard-only when action remains optional, slow, strategic, or dependent on broad interpretation. Remove it entirely when nobody can name a decision it supports.
Likewise, retire workflow rules whose cases are repeatedly dismissed, expire without useful action, or produce no measurable decision. A true condition can still be a poor use of attention.
Choose the surface from the decision
Use a dashboard when the metric helps people interpret a system. Use a workflow when a specific condition should become owned, timed, stateful work. Use both when reporting improves the rule and workflow outcomes improve reporting.
The implementation follows the expected decision. Choosing the dashboard tool first and hoping an operating model emerges afterward reverses that order.
More in this domain: Reporting
Browse allBI Engine: when it matters, when it's a trap
BI Engine can be useful, but only after you prove it is actually accelerating the workload you care about. Otherwise it turns into configuration thrashing around the wrong problem.
Precompute ladder: cache -> scheduled tables -> MVs -> extracts
Precompute is not mainly a feature choice. It is a freshness budget decision: use the cheapest mechanism that meets the reporting need, then stop paying live query cost out of habit.
Why your BI dashboards melt BigQuery
Dashboards do not passively read data. They generate repeated, variable workload, and that behavior is often the real source of BigQuery cost and latency pain.
A dashboard is not an operating system
Dashboards are good at showing state. They are bad at routing action, assigning ownership, and closing operational loops once a metric requires intervention.
Data Studio blending limits expose your real data model problems
When a report starts depending on heroic Data Studio blending, the issue is usually upstream structure, not dashboard craftsmanship.
Related patterns
What makes a KPI trustworthy enough to automate around
A KPI is not ready to drive action just because it exists on a dashboard. It needs stable meaning, reliable updates, and failure behavior that will not create new chaos.
When reporting logic belongs upstream instead of in the BI layer
If reporting logic affects business meaning, reuse, or trust, it usually belongs upstream where it can be reviewed, reused, and kept consistent across reports.
Alert configuration should control business behavior, not system structure
Alert configuration should make business behavior reviewable: wording, thresholds, variants, labels, routing, timing, and feedback options. Lifecycle guarantees belong in code.
Why alert feedback should be structured first
Free text helps, but structured alert feedback lets the system measure relevance, timing, duplicates, bad data, and rule quality. Human response becomes evidence the rules can learn from.