Status stored and not shown
The system knows a record is on hold, blocked or late, and the screen where users act does not show it.
Table of Contents
Summarize with:
Key facts
- The status exists in the data and is missing from the screen where users act.
- Users open records one by one to check their status.
- Blocked work gets started anyway.
- Supervisors ask for status by phone or chat.
- Status that matters for an action belongs on the screen where the action is taken.
How to spot it
- Users open records to check their status
- Blocked work gets started anyway
- Supervisors ask for status by phone or chat
- Lists show identifiers and dates and leave out hold or block flags
Why it happens
Status lives on the detail page. It was added as a field on the record and never brought into the lists and queues where work starts.
Each role sees a different screen. The planner who sets a hold and the operator who starts the job work on different screens, and the hold reaches only the planner’s.
Design consideration
Status added after the screens
Hold and block states were added to the data model later, and existing screens were not revisited.
What it costs
- Wasted work. Blocked work gets started anyway, and has to be stopped or reworked.
- Interruptions. Supervisors spend time answering status questions by phone or chat.
- Slow lists. Users open records one by one to find the ones they can act on.
- Lost trust. When the screen does not show what the system knows, users stop relying on the screen.
Where it shows up