Show what is stuck and who can act
Support staff should be able to find work that is overdue, blocked or repeatedly failing. The view should show the current state, last accepted action, responsible role and the next authorised recovery step.
A business refusal differs from a software failure. A participant may refuse a work item because required information is missing; a service may fail because a dependency is unavailable. The interface should describe the difference in ordinary terms.
Keep work history separate from software health
Work history is the durable record of accepted changes. It records the actor, authority, time, request, rule decision and result needed to explain how the work reached its current state.
Operational telemetry is the measurements and logs used to understand software health, performance, retries and failures. Logs may help diagnose a fault, but they should not be the only record that a person completed a work item. They should also avoid unnecessary personal or confidential information.
Recover through new recorded actions
The component should restart from durable state and replay only actions that are safe to repeat. Malformed or repeatedly failing input should be isolated so that other work can continue.
Manual recovery must identify the authorised person, reason and result. A corrective action, including one that counteracts an earlier action, creates a new history entry; support tools should not silently rewrite an earlier completion.
Treat accessibility as operational behaviour
Keyboard access, clear focus, readable status and understandable errors help participants complete work and help support staff diagnose problems. These qualities should be tested with the first interface rather than postponed until the component is considered complete.