← Back to Patterns

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.

By Ivan Richter LinkedIn

Last updated: Sep 1, 2026

4 min read

On this page

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:

  1. What should somebody do when it crosses the condition?
  2. Who is accountable for doing it?
  3. How quickly does action change the outcome?
  4. Can the system identify the affected case?
  5. What makes the case new, repeated, resolved, or expired?
  6. What does a wrong trigger cost?
  7. 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 all

Related patterns