Automation that survives contact with real data

An automation that works in testing and fails in production usually fails for the same handful of reasons. None of them are exotic, and all of them are cheaper to handle when you build than when you debug.

Assume every field can be missing

Test data is tidy. Real data has a contact with no last name, a company field containing a single full stop, and an email address with a trailing space. A workflow that assumes a field exists will fall over on the first record that disagrees.

Add a validation step immediately after the trigger that checks required fields and routes anything incomplete to a review queue rather than letting it through.

Fail loudly, in one place

Silent failure is the worst outcome, because you find out weeks later when someone asks why the numbers are wrong. Every workflow should have an error path, and every error path should end in the same place: a channel somebody reads.

One shared error destination beats per-workflow notifications. People mute channels that cry wolf, and a single well-behaved one survives longer.

Retry once, then stop

• Transient network errors deserve one retry after a short delay.
• Authentication errors deserve none. Retrying a bad credential will not fix it and may lock the account.
• Validation errors deserve none either. The data is wrong and will still be wrong in thirty seconds.
• Unlimited retries turn a small outage into a flood of duplicate records.

Make runs idempotent

If a workflow runs twice on the same input, the result should be identical to running once. This is the single habit that prevents the worst class of automation bug, the one that quietly creates duplicates for a fortnight.

In practice that means checking whether a record exists before creating it, and keying that check on something stable rather than on a name somebody might edit.

Watch the thing that matters

Monitoring an automation by whether it ran is not enough, because a workflow can complete successfully and do nothing useful. Monitor the outcome instead. If the job is meant to create records, alert when the count is zero for longer than it should be.