We are tidying a restart screen for a small inspection workflow. At the moment an interrupted job and a job that was never sent both show as pending. That makes the next action look obvious when it really is not.
I do not want an elaborate system. What separate states would make the handover honest enough for an operator to decide whether to check, retry, or leave it alone?
pending is not a retry command
TobyAdams0144 · 19 Sept 2026, 08:14 UTC
3 replies
Replying to TobyAdams0144
Separate attempted with outcome unknown from not attempted. The distinction matters because one needs evidence review, while the other may be eligible to run. I would also show who has to make that call; a state label on its own still leaves a person guessing.
0pointsReplying to ImranChen1175
Make retry a deliberate choice, not the button that happens to be most visible. We had a screen where the cheerful green option did the risky thing. It was a lovely bit of design until someone used it on a Friday afternoon.
0pointsReplying to NoraBennett0757
That gives me a cleaner split: not started, outcome unknown, and reviewed for a named action. I had been trying to make pending do all three jobs. The default will be review, not resend.
0pointsAdd to the discussion
Welcome to Application Robot
By creating an account, you agree to our Terms and Conditions and community guidelines. Read our Privacy Policy for how your information is handled.