Testing, monitoring, and handling errors

An automation that works on launch day but quietly fails a month later is worse than no automation, because everyone has stopped watching the task. This lesson covers the habits that keep workflows reliable: testing properly, launching carefully, and knowing immediately when something goes wrong.

Test like the real world

Most workflows pass a test with one perfect record and then fail on real data. Build a small test set that includes:

• Normal cases: three or four realistic examples of what usually happens
• Missing data: no phone number, no last name, an empty optional field
• Odd formats: names in all capitals, international phone numbers, dates written differently
• Duplicates: the same person submitting twice, or an existing customer
• Exceptions: spam, a cancelled order, an amount over your approval limit

For each, write down what should happen, run it, and compare. The prompt library includes a prompt that generates test cases from a workflow description.

Use test contacts and your own phone number for anything that sends messages. A test that texts a real customer "TEST TEST" is a memorable mistake.

Launch in stages

1. Internal run: trigger the workflow yourself several times and check every output.
2. Shadow mode: where possible, let the automation run alongside the manual process for a few days, sending its messages to you instead of customers, and compare results.
3. Partial rollout: turn it on for one location, one service, or one team member's leads.
4. Full launch: once results match expectations, turn it on for everything, and tell the team what changed.

Design for failure

Every step that talks to another app can fail: the app is down, a login expired, a required field is empty. Decide in advance what happens:

• Retry temporary failures automatically (most platforms can do this).
• Skip and log records that cannot be processed, so the rest keep flowing.
• Alert a person with enough detail to fix it: which workflow, which record, which step, and the error message.
• Never fail silently. If a customer message did not send, someone must know.

Monitor what matters

Each automation should have:

• An owner: a named person who receives alerts and makes changes.
• A run history: most platforms keep one; check it weekly at first, then monthly.
• A health check: a simple number that would look wrong if the automation stopped, such as leads replied to per day or invoices sent per week.
• A change log: a short note every time someone edits the workflow, with the date and the reason.

Why automations break later

Most workflows do not break on their own. Something around them changes:

• Someone renames a field, adds a required field, or changes a dropdown option in a connected app.
• A password changes or a connection's login expires.
• An app updates its API or retires an old feature.
• The business changes the process (a new service, a new pricing rule) but not the automation.

The fix is a habit: whenever you change a tool or a process, ask "which automations touch this?" Your workflow documentation from lesson three makes that a two-minute check.

In the final lesson, you will learn how to measure whether an automation is paying off and how to decide what to automate next.