Direct answer
Test an automation with real payloads and real failures. Build a staging setup that mirrors production, run it on sample data copied from actual records, then deliberately break it: send the same event twice, exceed a rate limit, let a credential expire, remove a permission, and turn a downstream system off. If the workflow handles each of those in a way you decided in advance, it is ready. If it only passes when everything works, it has not been tested.
This page is a checklist for workflow and integration automations. Design questions about what should happen to a failed run belong in workflow exception and escalation design, and model-specific behaviour is covered in AI automation failure handling. Here the concern is proving the behaviour before go-live.
Staging
A staging environment is only useful if it behaves like production where it counts. Use separate accounts or sandbox instances of each connected system, with their own credentials, so a test can never send a real email, change a real record or charge a real customer. Where a system has no sandbox, agree a clearly marked test area inside the live account, and write down what is safe to touch.
Check that the workflow's configuration is separated from its logic: endpoints, account identifiers, recipients and switches should be settings, not values typed into the middle of a step. If moving from staging to production means editing the workflow by hand, that edit is itself a risk, and the go-live check should confirm it was done correctly.
- Every connected system has a non-production target, or a documented safe test area.
- Staging credentials cannot reach production data.
- Outbound messages in staging go to internal addresses only.
- Differences between staging and production are listed, not assumed.
Sample data
Invented data is tidy. Real data is not. Take a set of genuine records, with personal or confidential details removed or replaced where needed, and run them through the workflow. Include the awkward ones on purpose: missing fields, very long text, unusual characters, names with accents, dates in another format, empty lists, and records that were edited by hand years ago.
Ask the people who run the process which records caused trouble last time. Those are the best test cases you will get. Keep the set and reuse it: every later change to the workflow should be run against the same records so you notice when something that used to work stops working.
Duplicates and replay
Most integrations will, at some point, deliver the same event twice. A webhook is retried, a user clicks twice, a scheduled job overlaps with the previous run. Test this directly by sending the same payload two or more times and confirming that the outcome is the same as sending it once: one record created, one email sent, one invoice raised.
Then test replay. When a run fails halfway, someone will want to run it again. Confirm that a rerun picks up where it should, does not redo steps that already succeeded, and can be triggered by a person without editing anything. If the safe way to rerun is undocumented, write it down before go-live.
Rate limits
External systems limit how fast they will accept requests. Look up the limits of each connected system, then test what happens when the workflow meets them: a bulk import, a backlog after downtime, a month-end burst. The workflow should slow down and retry rather than drop items or fail the whole batch.
Check also that a rate-limit response is treated as temporary while a genuine rejection is treated as permanent. Retrying a request that will never succeed wastes capacity and hides the real problem.
Credential expiry
Credentials expire, get rotated, or are revoked when the person who created them leaves. Test what the workflow does when a token is no longer valid: it should stop cleanly, keep the affected items, and alert a named person, not fail silently or retry forever. Note which credentials have an expiry date and put that date in someone's calendar.
Where possible, use a dedicated service identity for the integration, not a named employee's login, so the automation does not break when that person changes role. Who holds and renews each credential should be written down as part of the handover.
Permissions
An automation should have the least access it needs. Test both directions: confirm it can do everything the process requires, and confirm it cannot do what it should not, such as deleting records or reading unrelated data. Then remove one permission and observe the failure. The message should say what is missing, not just that something went wrong.
Also check who can change or disable the workflow itself. Editing an automation is a form of changing the business process, and it deserves the same control as any other change.
Monitoring
Decide how you will know something has gone wrong, and test that the signal arrives. Trigger a failure in staging and confirm that the right person receives a message that identifies the workflow, the item and the step. A log nobody reads does not count as monitoring.
Cover the quiet failure as well as the loud one: a workflow that simply stops running produces no errors. A simple check that expects activity, and warns when none arrives, catches a whole class of problems that error alerts miss. Keep whatever tooling you use proportionate; the point is a tested route from failure to a person who can act.
Go-live
Before switching on, confirm the following: the tests above passed on the agreed sample set; production settings were checked by a second person; the alert route is live; there is a documented way to pause the workflow and to run items manually if it fails; and the owner knows what normal looks like. For the first period after launch, review the results by hand rather than assuming they are right.
Keep the checklist, the sample set and the test results with the handover material. They make the next change cheaper and give anyone maintaining the workflow a place to start.
Questions
Is a successful run in staging enough to go live?+
No. It shows the happy path works. You also need to see duplicates, rate limits, expired credentials and missing permissions handled the way you intended, because those are the situations production will produce sooner or later.
Can I test with production data?+
Prefer copied or masked records in a non-production setup. If a system has no sandbox, agree a clearly marked test area inside the live account and write down exactly what is safe to touch.
How do I test credential expiry without waiting?+
Revoke or replace the staging credential on purpose and observe what the workflow does. The check is that it stops cleanly, keeps the affected items and alerts a named person.
Who should sign off an automation?+
The person who owns the process it automates, not only the person who built it. They know which awkward cases matter and what a correct outcome looks like.
Does LATYNEX include testing in an automation project?+
Testing against agreed scenarios is part of how we scope work. The scenarios and what counts as passing are written into the scope before work starts, and we will say plainly if a system offers no safe way to test.