Workflow automation: an integration checklist before you launch

Write the workflow as a business event with a completion condition. 'A qualified enquiry creates one assigned CRM opportunity' is clearer than 'connect the website to sales'. Identify the source of the event, the required fields and the destination owner. Decide whether completion means a record exists, a person accepts it or the customer receives confirmation.

Sketch the manual exceptions alongside the normal path. Existing customers, duplicate submissions and incomplete details should not be discovered only after release. Where a decision has stable rules, implement those rules directly. Add AI only where interpreting unstructured information creates a real benefit and where the result can be checked.

Agree what each field means across systems. A status called 'active' in one tool may mean something different in another. Specify required values, identifiers, date formats and how missing data is represented. Preserve an authoritative record rather than letting every connected tool overwrite the others without a policy.

Use realistic test records, including accented characters, long names and missing optional fields. Keep personal information to the minimum the process needs. When a form changes, the integration should flag incompatible input rather than quietly creating partial records. A validation failure is useful if someone can see and resolve it.

Many event systems can deliver an event more than once. Design the destination action so repeating the same event does not create another booking or message. Store a stable event identifier and use it to recognise a completed operation. This is particularly important when the sender retries because it did not receive confirmation.

Distinguish a temporary outage from invalid input or missing permission. Temporary failures may be retried with limits; invalid records need correction. If one of several steps succeeds, retain that state so recovery does not repeat the whole chain. An operator should be able to see which step completed and what remains.

Grant the integration only the access needed for the workflow. Separate test and live credentials, store secrets safely and consider what happens when access is revoked. If an AI layer can request an action, the execution layer must still verify permission and business rules. Never depend on a prompt to enforce an irreversible-action limit.

Test the fallback as deliberately as the success path. Can a person find the failed request, read the relevant context and finish it without starting over? Is the customer told the true status? If the fallback is a mailbox nobody monitors, the integration is not operationally complete.

Document the trigger, dependencies, permissions, expected volume and recovery steps in language the responsible team can use. Set a review process for changed forms, API changes and new business rules. Monitor unresolved items and duplicate attempts as well as successful runs; a high success count can hide an accumulating exception queue.

For an automation brief, bring one real workflow and representative input examples, with private information removed or shared only with permission. I use that material to map the integration, decide where AI is justified and define a pilot that can be supported after launch.