Workflow & automation
Before you automate a handoff, define the exception.
Map one request from arrival to completion, including missing information, failed transfers, and the decision to stop or retry.
A customer submits a request. Someone checks it, enters it into another system, and tells the next person the work is ready.
That sounds like a straightforward automation opportunity. Before choosing the tools, we would ask the people doing the work to walk through one ordinary request and one difficult request. The difficult example often reveals the decisions the automation will need to preserve.
Write down the moment responsibility changes
For each handoff, identify the sender, the recipient, the information passed, and the condition that makes it ready. “Sent” and “accepted” are different events. Decide what evidence the team needs to know the next person or system has taken responsibility.
For a field service visit, the handoff might include the customer, address, service scope, assigned date, and completion requirements. Someone needs authority to decide whether those details are sufficient to release the work.
Bring the exception into the design
Choose a few specific situations and agree what should happen. The following is an illustrative design exercise, rather than a ready-to-use configuration.
| Situation | Decision to define |
|---|---|
| The address is incomplete | Who asks for the missing information, and where does the request wait? |
| The receiving system rejects the request | Who sees the failure, and what makes it safe to retry? |
| The sender submits the request twice | How is a duplicate identified and reviewed? |
| The assigned date changes | Which system owns the date, and who needs the update? |
Give the waiting work a visible place
Define how someone finds a request that could not advance. Include its current status, the last completed action, the reason it stopped, and the person responsible for the next decision. Agree how the team will notice work that has waited too long.
This can be a simple queue in the first release. Its purpose is to make unresolved work visible and give someone a way to recover it.
Test recovery alongside the ordinary path
Ask the builder to demonstrate the agreed scenarios with sample records. Watch what happens when information is missing, when the transfer fails, and when an authorized person retries it. Check the record in both systems and confirm who owns the result.
Use those observations to refine the acceptance criteria. A clear criterion might be that a rejected request remains visible with a reason and a named owner. Another might specify how a repeated submission is recognized and reviewed.
Record where the request starts, who accepts it, what information is required, and one exception the team handles by judgment. That is enough to begin scoping a useful first automation.