Start where information changes hands.
An enquiry arrives in an inbox. Someone enters it in a customer system, sends a confirmation and creates a task for another person. Connecting those steps can be useful. But first decide which step establishes the record and which person is accountable for it.
Without that decision, automation can spread an incorrect value faster than a person could copy it. Map the source, destination, required fields and expected result. Then decide whether the proposed connection removes enough repeated effort to justify operating it.
Choose one record of truth.
A customer’s email address might exist in several tools. Which tool is allowed to change it? How do those changes reach the others? A workflow needs an answer before two systems begin writing over each other’s data.
Use a stable identifier to connect related records. Names and email addresses can change. A shared order or request identifier makes it easier to trace what happened and avoid creating a second record when a task is retried. The exact approach depends on the systems being connected and the guarantees their APIs offer.
Design the failed attempt.
A successful request is only one branch of the workflow. External services can be unavailable, credentials can expire and a response can arrive after the caller has stopped waiting. Decide which failures can be retried, how often and what should happen when the attempts are exhausted.
Stripe’s documentation on idempotent requests is a useful concrete example: an operation can carry a key so a retry does not automatically mean a duplicate action. That behaviour is specific to the API and operation. Do not assume every tool supports it, or that a retry is harmless.
Give the exception a visible destination.
A failed workflow should create something a person can act on: the request, the reason it stopped, the previous attempts and the next safe step. Sending every failure into a busy inbox is often just another way of hiding a queue.
Agree who checks that queue and how they recover the work. Include a way to correct bad information without silently losing the original request. A practical automation project connects the normal path and the recovery path. Both need an owner.
Add AI only where judgment can be checked.
Extracting fields from a document or suggesting a reply may be a useful place to test an AI tool. Define the task, use representative examples and decide what counts as an acceptable result. Keep a review step for actions where an incorrect suggestion would matter.
NIST’s AI Risk Management Framework offers a structured way to think about context, measurement and management. It is a useful reference, not proof that a particular tool is safe or accurate. Begin with a bounded workflow, record what you learn and expand only when the evidence supports it.
