From reading to action
A practical path through this guide.
Select a step to explore what to do and why it matters.
Define observable behavior
Write what should happen to a valid input at the destination.
Automation acceptance criteria describe observable business behavior, including failure and recovery. They turn “connect our tools” into a deliverable both the client and developer can assess. Write them before implementation so demonstrations cannot quietly replace evidence.
Describe inputs and outcomes
Use a concrete statement: “Given a valid enquiry with a unique submission ID, when the form is submitted, create or update one CRM contact and assign the agreed owner within the target processing window.” Define the window together; do not assume every workflow needs instant delivery.
Specify the required fields and what happens when each is absent. A missing company name might be acceptable. A missing contact address might require review. The automation should follow business rules rather than invent placeholder customer data to satisfy an API.
Cover the difficult paths
- Submit the same event twice and check that only one business action occurs.
- Simulate a temporary destination failure and inspect bounded retries.
- Remove a required field and confirm that the record enters a visible exception queue.
- Revoke access and verify that an owner receives a useful alert.
- Replay a failed record and confirm that previously completed actions are preserved.
Give each test an expected destination state. “No error appeared” is insufficient when the workflow silently drops a branch. For a notification, inspect the recipient and content; for a record update, inspect the actual changed fields.
Separate delivery from service commitments
Document the supported applications, account access, operating environment, volume assumptions, and excluded cases. State who pays subscriptions and who owns credentials. Include which future changes require a separate estimate.
Support hours and response expectations belong in the maintenance agreement. A successful implementation does not imply continuous monitoring or round-the-clock response. Put the handoff date and escalation route in writing so neither side has to infer the arrangement.
Package the evidence
Deliver a short test record with input identifiers, expected results, actual results, and any unresolved limitations. Include the workflow export or version reference, a recovery guide, and instructions for disabling the flow safely.
Use sanitized fixtures so the client can repeat the demonstration without exposing real customer information. Have the business owner confirm that the destination state matches how their team actually works. Technical validity and business correctness are separate checks.
Further reading
Pair these criteria with an automation handoff document. The implementation or repair offer uses a narrowly agreed scope so delivery stays reviewable.
A few practical answers
Frequently asked questions
What makes an automation acceptance criterion testable?
State the input, trigger, destination outcome and agreed processing window. Include expected handling for missing fields, repeated events and failed dependencies.
Does implementation automatically include ongoing support?
No. Delivery scope and maintenance commitments should be explicit. Agree support hours, escalation contacts and responsibilities separately from the implementation acceptance evidence.
