A safety workflow app is not really a form. It is a promise that what someone writes down will reach the person who needs it, in time to matter. Most digital safety processes fail on that promise long before they fail on usability.
A polished screen can still reproduce every weakness of the paper process it replaced. If the workflow has no clear owner, no response time and no way to see what happened next, digitising it only makes the unresolved work easier to count.
It has to be quicker to do properly than to defer
If completing the record at the time of the work takes longer than remembering to do it later, it will be done later, from memory and in a batch, with the detail that mattered already gone. Design for the person standing in front of the job with gloves on, not for the person reviewing records at a desk.
That means asking only for information the person can know at that point. Equipment, location, condition, immediate action and the help required are useful. A long classification list written for monthly reporting can wait until triage, when someone with the right context can complete it properly. Forcing every field onto the first person usually produces guesses rather than better data.
The workflow also needs to tolerate the real environment: poor reception, shared devices, noise, dirty hands and short windows between tasks. A process designed around a quiet desk will be deferred on the floor, regardless of how well it performed in a demonstration.
The record has to reach a named person, not a queue
A completed record that lands in a shared inbox or a report nobody owns is information that technically exists and practically doesn't. Every flagged item needs a destination: a specific person, a visible state, and a way for the person who raised it to see that it moved.
Routing should follow the nature and urgency of the issue, not one universal approval chain. An immediate hazard, a damaged guard and a request to improve a form do not need the same response. Each needs an owner, a due point and an escalation path when nothing happens. Without that, a dashboard of open items becomes a record of delay rather than a control.
Closing the loop has to be part of the design
Closure is more than changing a status to complete. The person who raised the issue should be able to see what was done, who accepted any remaining risk and whether the change affects the way the job should now be performed. If they never hear back, they cannot judge whether reporting the next issue is worth the effort.
A useful workflow records the conversation around the decision without turning it into an essay. A short response, an owner, a date and supporting evidence are often enough. The record then helps the next shift and the next review, rather than serving only as proof that someone clicked a button.
It has to be useful to the person who filled it in, not just to whoever audits it later
Records that exist purely for audit purposes get treated as an audit chore. Records that give something back to the person completing them, such as a clear view of outstanding items, a useful history and confirmation that what they flagged was acted on, get treated as a genuine tool. How a record is experienced by the person filling it in is often the real determinant of whether it gets completed honestly or backfilled from memory.
Why this connects to a historical failure, not just good UX
This week's historical post covers Piper Alpha, where a written safety warning existed on paper the same day, in the same building, but never reached the people who needed it because two related records were filed separately and depended on a manual handover to be connected. That's the same underlying problem a badly designed digital workflow can recreate: information that exists, technically, but isn't structured to reach the person who needs it when they need it.
Getting that structure right is what our Power Platform and business applications work is for, and it's why we treat safety workflows as an information-routing problem first and a form-building problem second.
Test the route before adding more fields
The quickest test is to follow one realistic issue from the person who notices it to the person who can authorise the response. Note every handoff, notification and decision. Then check whether the original person can see the outcome without chasing anyone. This exposes routing gaps faster than reviewing the form field by field.
Only then should the team discuss extra data. A field earns its place when someone uses it to route, assess or decide. If nobody can name that use, remove it or collect it later. Shorter forms are not automatically better, but every unnecessary field competes with the detail that may matter during the event.
Build for exceptions, not only the happy path
Workflow demonstrations usually show a complete record moving neatly from submission to approval. Real work brings duplicate reports, unavailable approvers, disputed closures, urgent escalation and issues that cross departmental boundaries. The design needs a clear response for each without relying on somebody remembering an informal rule.
Permissions deserve the same attention. People need enough access to report and follow their own issues, while sensitive information remains limited to the right roles. Test these boundaries with the people who will use the process on different shifts and devices. A workflow that works only for the project team has not been tested in the conditions that matter.
Review the process after launch
Watch where records wait, where users abandon them and where administrators correct information by hand. Those are process signals, not merely support requests. A short review after the first few weeks should remove fields nobody uses, tighten routes that create delay and make common outcomes easier to understand.
What to check this week
| Question | If the answer is concerning |
|---|---|
| Is your current safety/approval record usually completed at the time of the work, or afterwards? | The process is likely harder to use than to defer |
| Does a completed record reliably reach the specific person who needs to act on it? | You likely have a queue problem, not a completion problem |
| Does the person filling in the record get anything useful back from it? | It's probably experienced as an audit chore, not a genuine tool |
Where to go next
The Approval Process Check, a separate assessment from the app I'm building, is still being written. Until it's published, run the three questions above against your own process and write down where it falls over. If it scores poorly, that's a genuinely fixable design problem, and one I'm actively working through myself. If you'd like to talk it through in the meantime, get in touch.