Designing for Failure

Automations do not fail loudly. An app times out, a credential expires, a field is renamed — and the workflow quietly stops. You find out weeks later when someone asks about a lead that never arrived.

This is the specific danger: you stopped doing it manually because the automation was handling it. Trust without visibility is how automation causes damage.

The failures worth planning for

• A connected app is down or slow — will your run retry, or die?
• A credential or token expires — the most common cause of a workflow that worked for months and then stopped
• Input is malformed — an empty field, an emoji, a phone number as text, a duplicate submission
• The AI step returns something unexpected — a category you did not define, or prose where you wanted JSON
• The workflow runs twice on the same item — a retry, a double submission, a webhook delivered twice

Make repeat runs harmless

The one property worth engineering deliberately: running the same item twice should produce the same result as running it once. That means checking whether the record already exists before creating it, and keying on something stable like a submission ID.

Without this, every retry creates a duplicate — and duplicates in a CRM or an accounting system take far longer to clean up than the automation ever saved.

Run it alongside the manual process

For one to two weeks, keep doing the task manually while the automation runs in parallel. Compare the outputs.

This is where you discover the case you did not think of, at the point where the cost is noticing a mismatch rather than losing a customer.

Document the off switch

1. Where the automation lives and how to open it
2. How to disable it in under a minute
3. What breaks downstream when it is off, and who needs to know
4. How to do the task manually while it is disabled
5. Who owns it besides you

That last point matters more than it sounds. An automation only one person understands is a liability the week that person is unavailable.