A customer sends a request. An approval arrives. Then the next step stops. The tracker still says “waiting,” and nobody knows whether to try again.
That moment belongs in the design conversation before a workflow goes live. A useful workflow needs a clear way to recognize a problem, protect work that already happened, and get the process moving again.
Start with what “finished” means
A notification sent is not always a task completed. If a request needs an approval, an updated record, and a customer confirmation, define those as separate outcomes. Give the team a way to see which steps actually finished.
Consider a fictional equipment request. A manager approves it, but the stock record cannot be updated. Calling the whole request “complete” hides unfinished work. Calling it “failed” without showing the approval may encourage someone to ask for the same decision again.
A clearer status is “Approved — stock update needs attention.” It tells someone what is known and what remains.
Give failures an owner and a next step
A warning is useful only if someone can act on it. Decide who checks problems, how they are notified, and who covers that responsibility when they are unavailable.
The alert should identify the affected request, describe the incomplete step in plain language, and point to the approved support process. Avoid putting private customer details into broad notification channels.
Agree when the team should pause new work, continue with an approved manual fallback, or escalate. Those decisions depend on the consequences of a missed or repeated action.
Check before trying again
Repeating an entire workflow can repeat things that succeeded. A second run might send another customer message, create another task, or submit another order.
Before a retry, establish which actions completed and which did not. Use a stable request reference so an authorized person can match the workflow to the business record. Design recovery around the incomplete step where practical.
For actions with meaningful consequences, an unclear result deserves investigation. A missing confirmation does not prove nothing happened.
Test the awkward cases
A demonstration with one complete request shows the normal route. It does not show how the team will recover when information is missing or a connected service is unavailable.
- Submit an incomplete request and confirm what the user sees.
- Test an unavailable approver and the agreed cover arrangement.
- Simulate an interrupted update in a safe test environment.
- Repeat the same request and check for duplicate work.
- Ask the support owner to follow the recovery instructions.
Record the expected result and the actual result. Keep tests away from live customers, orders, and payments unless a specifically agreed test procedure makes that safe.
Keep a small recovery guide
The guide can be short: the symptom, the checks to make, the responsible role, the tested recovery steps, and the point at which to escalate. Include the approved fallback and how its records will be reconciled afterward.
Review it when the workflow changes. A recovery instruction that describes an old process can create more confusion during an interruption.
A practical starting question
Choose one workflow your team relies on. Ask: “If this stops halfway through tomorrow, who will notice, what will they check, and how will we finish the work without repeating it?”
If the answer is unclear, that is a useful improvement to make before adding more automation.
At Solvency Studio, the starting point is understanding the work, including the exceptions. The goal is a process your team can use and support with confidence.
Understand first. Automate second.
Discuss a workflow that needs attention