PROCESS AUTOMATION
What happens when an automated process gets stuck
An automated process can finish one step and fail at the next. For a business owner, the important question is whether the unfinished work remains visible, and whether somebody can recover it without creating another problem. Before trusting a workflow with live enquiries, give its recovery plan the same attention as its successful run.
Practical design guidance. The enquiry described is hypothetical.
Consider a hypothetical enquiry arriving in a shared inbox. The automation sends an acknowledgement, then tries to create a record in the customer relationship management system, or CRM. That second step fails. The customer has heard from you, but the sales team may have no record to follow up. Repeating the whole process could send another acknowledgement or create a duplicate record.
Understand why the work stopped
Start by separating problems that need different responses. A temporary service outage may justify trying again later. Missing information needs correction or a request for the missing detail. An enquiry outside agreed rules needs somebody with the authority to decide what happens next.
Microsoft's work queue guidance distinguishes technical exceptions, business exceptions and work placed on hold. That distinction is useful beyond any particular product. A retry cannot supply a missing answer or make a commercial judgement. Decide which conditions allow the process to continue, and which should pause it.
Keep unfinished work in view
We recommend a shared exception list: a practical record of work that has stopped and still needs attention. It should show the enquiry reference, how long it has been waiting, the reason, a named owner, the last confirmed action and the next step. Keep sensitive details in the appropriate system, with a link for authorised staff.
For the hypothetical enquiry, the record might say: acknowledgement confirmed; CRM record not confirmed; owner to check the CRM before resuming. The distinction between an attempted action and a confirmed result matters.
Agree when that list is reviewed and when an overdue item goes to someone else. Base the timing on the consequence of delay. A routine information request and a time-sensitive order may need different attention. An alert should point to the record that needs action, rather than leave staff piecing together several emails.
Retry carefully and check the outcome
For temporary faults, set a waiting period and a maximum number of retries. Microsoft's error-handling guidance supports retry limits and increasing the interval between attempts. Once that limit is reached, stop retrying and make the unresolved item visible to its owner.
Before enabling retries, establish how duplicates will be prevented. AWS's guidance on safe retries explains why a missing response does not necessarily mean an action failed. Repeating the request can repeat its effect unless the receiving system recognises it as the same operation.
Ask the person building the workflow to demonstrate that protection. A unique reference helps only when the system actually uses it to prevent duplicate effects. Where the outcome is uncertain, check the destination record before deciding whether to retry. Mark the enquiry complete only when the required result has been confirmed.
Test the awkward cases
Before launch, test a missing field, an unavailable service, the same enquiry arriving twice and a connection failing after the CRM has saved the record. Use test data. Ask a colleague who did not build the workflow to recover an item using the information provided.
After launch, review how long unresolved items remain open and how much staff time goes into correcting or reconstructing work. Look for recurring causes. A process that completes many routine tasks can still deserve attention if the remaining cases are difficult to recover.
Make recovery part of the design
No Staff's own-ventures-first philosophy asks a practical question: would we trust this workflow in a business of our own, including on a difficult day?
The aim is to support an existing team with clearer records and fewer repetitive tasks. Staff should retain the context and authority to resolve exceptions. A useful first step is to choose one workflow and ask its owner to show what happens immediately after it stops.