Automation / A practical guide
What happens when a business automation fails halfway?
A connected workflow needs a clear answer for unfinished work: what completed, what is still waiting, and who can recover it without repeating the wrong action.
Follow one job through every system
Imagine a service business where an approved request creates a delivery task, updates a customer record, and sends a confirmation. The task is created, but the customer-system update fails. Should the workflow start again? Send the confirmation anyway? Ask someone to finish it? Without an agreed answer, the team can end up with duplicate tasks and an apparently completed request that still needs attention.
This is an illustrative design example, not a client case study. It applies whether the connection uses a visual automation platform or custom code. Before choosing tools, draw the steps for one real business outcome. Mark which steps change records, which contact people, and which depend on earlier steps succeeding.
Agree what counts as complete
Give each request a stable reference that can be followed across the connected tools. Define the evidence for each completed step: for example, a delivery-task identifier and a confirmed customer-record update. Keep the overall job open until the required outcomes are established. A successful trigger or a green connector step may cover only part of that journey.
Ask for a view that separates waiting work, completed work, and work requiring attention. These labels should have concrete meanings. If the system does not know whether an action succeeded, show that uncertainty rather than turning a timeout into a definite failure or success.
| Situation | Useful business state | Next step to agree |
|---|---|---|
| Nothing has been changed yet | Waiting to start | Retry within the agreed limit or route to an operator. |
| The task exists; the customer update failed | Partially complete | Keep the task reference and recover the missing update. |
| The service stopped responding after a request | Outcome unknown | Check the destination before repeating a consequential action. |
| Required steps have been verified | Complete | Record the evidence and close the job. |
| A record does not meet the business rules | Needs review | Explain the rejected field or rule and assign an owner. |
Ask what a retry will actually repeat
Microsoft's Retry pattern distinguishes short-lived faults from failures that repeating the request will not fix. It recommends a retry policy suited to the operation, with bounded attempts and appropriate delays. It also warns that a service can complete an action but fail to return the response, making a blind retry repeat the action.
For a business review, ask the supplier to demonstrate the same request being attempted twice. The agreed result should occur once, with the repeat recognised rather than creating another task or sending another message. Engineers call a safely repeatable operation idempotent. Ask which identifiers and destination capabilities make that protection work, including when two attempts overlap.
Recovery should continue from the verified incomplete step where the workflow allows it. A single 'run everything again' button is risky when earlier steps have already changed external systems. If the outcome cannot be checked safely, keep the job for human review.
Expect duplicate and delayed notifications
Many integrations start when one service sends another an event notification, often called a webhook. Stripe's documentation is a concrete example: events can be delivered more than once, and delivery order is not guaranteed. It describes tracking processed events to avoid duplicate handling. Check the actual delivery rules of each service in your own workflow rather than assuming every connector behaves identically.
Ask what happens if an older update arrives after a newer one. A request that has already been cancelled should not quietly become active again because an earlier notification was delayed. Agree which system owns the current status and how conflicting updates are resolved. Names and display labels can change, so record matching should use stable identifiers where the systems provide them.
Look for gaps between saving and passing work on
AWS describes the dual-write problem: updating a database and sending a notification can leave inconsistent results if only one operation succeeds. Its transactional outbox pattern records the change and the event together before a separate process forwards the event. Duplicate handling still matters.
You do not need to prescribe that architecture in a small business brief. Ask the practical question: if the workflow stops between saving a request and passing it to the next tool, how will the missing handoff be found and completed? Your supplier should explain the chosen mechanism and its limits. Some platforms provide suitable history and replay features; others need additional tracking.
Also decide whether undoing a completed step is appropriate. Deleting a task that someone has already started may cause more confusion than leaving it visible with a recovery note. Recovery rules should reflect the business consequences, not merely restore a tidy technical status.
Make unfinished work someone's responsibility
A failure email is useful only if it reaches someone who can act. Name a primary owner and backup, decide how quickly different problems need attention, and show the request reference, last verified step, and available recovery action. Keep confidential information out of broad alerts; link authorised staff to the appropriate record instead.
Include a way to spot work that never triggered the automation at all. At an agreed interval, compare eligible source requests with the destination outcomes. Review missing or mismatched records and the age of unfinished work. This reconciliation check answers a different question from whether the automation service itself is online.
For a low-volume workflow, a small exception list and a documented manual check may be sufficient. Choose monitoring and recovery effort around the consequences and volume of missed work rather than adding infrastructure by default.
Test the awkward cases before handover
Ask for a supervised recovery demonstration in a suitable test environment using non-sensitive sample records. Define expected results before the test and inspect both connected systems afterward. A useful acceptance record includes the starting state, fault introduced, actual outcome, and evidence that unrelated records were not changed.
- Submit the same request twice, including overlapping attempts, and check that the intended result is not duplicated.
- Interrupt the connection after one step completes; recover the missing step without repeating completed actions.
- Return a temporary service error and show that retries stop or escalate according to the agreed policy.
- Return an invalid field or business-rule error and show a useful review path instead of endless retries.
- Deliver an old update after a newer status and confirm the current state is preserved or explicitly reviewed.
- Pause the workflow, handle one item manually, then resume and check that it is not processed again unintentionally.
- Create an eligible source record without its expected destination outcome and demonstrate how reconciliation finds it.
Put recovery into the project scope
Before commissioning the integration, write down the outcome, source of truth, stable references, completion evidence, retry boundaries, exception owner, and manual fallback. Agree who maintains the connection when a field, permission, or vendor API changes. Have the operator follow the recovery instructions without the builder guiding every click.
Bring one workflow and an example of unfinished work to a scoping conversation with KazeZeus. Udbhav can help define the integration and its acceptance checks around the business outcome, including how your team will operate it when a connected service is unavailable. That makes recovery part of the deliverable rather than an assumption discovered after launch.