Plan an operations dashboard around the next decision.

Name the user and the decision

Start with one role and one repeated operating decision. A dispatcher deciding which job needs assignment has different questions from an owner reviewing completed work. Combining every audience into one screen can hide the action each person needs to take.

Write the decision in plain language: identify unassigned work, find blocked jobs, review handoffs waiting for approval or confirm which tasks are due today. If a view cannot be tied to a decision, it may be a report people glance at rather than an operating tool.

• Who opens this view?
• What decision must that person make?
• Which records are included?
• What action follows the decision?
• Who handles an exception?

Separate an action queue from a summary

An action queue identifies specific records that need attention. A summary describes a broader pattern. Both may be useful, but they should not be treated as the same thing.

For example, a count of five blocked jobs does not tell staff which jobs are blocked, why they are blocked or who can resolve them. If a number is meant to trigger work, provide a route to the underlying records and the next responsible role.

Keep the first view focused. Additional filters and charts should answer a defined question rather than filling available space.

Define every status and date

Agree what each status means before building a visual layer. Terms such as new, scheduled, active, waiting, blocked and complete need observable rules. Two staff members should not apply the same status to different situations.

Dates also need definitions. Created date, promised date, scheduled start, last update and completed date answer different questions. Label the date being shown and explain which one controls an overdue rule.

Document the condition that moves a record into and out of each state. Keep judgement with a person when the business cannot express the rule reliably.

• The event that creates the status.
• The person or system allowed to change it.
• Required information before the change.
• The date used for ordering or escalation.
• The next valid states and exception path.

Identify the authoritative record

For each field on the dashboard, name where the value originates and which record controls the operating decision. If staff can change the same status in two places, decide which one is authoritative and how a conflict becomes visible.

Do not copy every available field into the dashboard. Include information needed for the defined decision, then provide a clear path to the underlying record when more detail is required.

Any connection between tools must be confirmed against the actual products, account plans and access available to the business. This guide does not promise that a particular integration is supported.

Make freshness and missing data visible

A zero can mean there is no work, but it can also appear when information failed to load. Treat no matching records, missing information, a failed update and stale information as different states.

Show when the relevant information was last updated and what the user should do if it is older than expected. Avoid describing a dashboard as real time unless the complete data path and update behaviour have been tested.

If a required field is missing, identify the record and the person responsible for correcting it rather than silently excluding it from the view.

• No records match the current rule.
• A required value is missing.
• The latest update failed.
• The information is older than the agreed threshold.
• The source is unavailable and a manual check is required.

Keep the owner and next action together

A highlighted problem is more useful when the view also shows who owns the next action. Define the owner as a person or role, not a department that everyone can assume someone else is monitoring.

Allow staff to reach enough context to act without rebuilding the record from messages or memory. The detail view should explain why the item appeared, which information controls it and what completion will look like.

If an item is reassigned, keep the current responsibility clear and decide whether the earlier handoff needs to remain visible.

Set role boundaries before sharing the view

Different roles may need different records and actions. Define who may view, assign, change, approve or export information. A summary for an owner does not automatically need the same record-level detail as a staff action queue.

Use fictional or specifically approved information during early testing. Privacy, retention, access and regulatory requirements depend on the business and data involved and should be reviewed with the appropriate advisers. A role-based design is not by itself a security or compliance guarantee.

Test decisions, not just display accuracy

Build acceptance cases around the work the view is supposed to support. An illustrative field-service test set could include one unassigned job, one blocked job, one overdue task, one recently completed job and one record whose latest update failed. These are planning examples, not 1120 client results.

For each case, record the starting information, the expected place in the view, the intended staff action and the result after the record changes. Test an item leaving the queue as carefully as an item entering it.

Ask a representative user to explain what needs attention without coaching. If the view requires hidden knowledge, revise the labels, definitions or detail path before adding more features.

• The correct records appear under the agreed rule.
• The order reflects the defined priority or date.
• The responsible role can reach the underlying record.
• A completed item leaves the action queue when expected.
• A stale or failed update is not presented as current.
• A user without the required role cannot perform the action.

Document fallback and ongoing ownership

Decide how staff continue the essential work when the dashboard or a source is unavailable. The fallback might be a review of the authoritative system, a manual assignment list or a named communication route. It should state who starts it and how normal operation resumes.

After launch, name who reviews failed updates, corrects status definitions, manages role changes and approves new dashboard requests. A dashboard reflects an operating process that will change; ownership belongs in the scope.

Choose practical measures tied to the intended decision, such as whether unassigned items can be identified and resolved. This guide does not forecast time savings, revenue or operational improvement.

Bring one operating decision to 1120

1120's published capabilities include operational dashboards, role-based views for jobs, tasks, dispatch and handoffs, workflow design, automation and custom business systems.

Bring one staff decision, the records used to make it and the difficult exception. That creates a bounded starting point for discussing an operations view. Data sources, integrations, permissions, architecture and deliverables require project-specific assessment before they are committed.

Start with your business process.

Describe how customers reach you and what your team needs to do next.

Explore 1120 capabilities