You will test your workflow's error handling by causing the common failures yourself.
Open your flow's run history and look for a run where your error path actually ran. If you can't find one, you don't yet know whether your error handling works.
By now you've added alerts, an error path, a log and an approval step to your flow. On paper the flow handles failure, but you haven't seen it fail. An error handler that has never run is only a guess. You don't want to find out whether your alert works on the night a real enquiry goes missing. So you break the flow on purpose, in a controlled way, and watch what happens. You run five tests, and each one matches one of the common failure causes from lesson 7.1, How automations fail, and why you often do not notice.
Pick a quiet time, when a real enquiry arriving mid-test wouldn't matter much. If your tool allows it, you can switch the live trigger to a copy of the form and sheet instead. Warn anyone else who receives alerts from the flow that some test alerts are coming, so nobody acts on them.
Next, set up a failure test record. This is a table with seven columns: test number, what you broke, what you expected, what actually happened, did an alert arrive, did the log record it, and what you fixed. Fill in the "what you expected" column for every test before you run it, so you have something to compare each result against.
Test 1 is empty input. Submit the form with all optional fields blank and the required fields as short as the form allows. Watch for a confirmation that reads "Hi ,", a branch with nothing to route on, or an AI step that receives nothing to classify.
Test 2 is very long input. Paste several paragraphs into the message field, the kind of message a worried parent might write at midnight. Some steps cut off long text, some fail, and an AI step may behave differently when it gets a lot of text.
Test 3 is badly formatted input. Enter a phone number with letters in it, a date written as "next Sat", and a name in capitals with an emoji. This checks the formatting steps from lesson 2.3, Format dates, names and numbers on the way through, and the defaults you set for values that don't fit.
Test 4 is a renamed column. Rename a column the flow writes to, for example "Phone" to "Mobile", then submit a normal enquiry. You're finding out whether the flow fails loudly or silently. To fail loudly means the flow errors and sends an alert. To fail silently means the flow reports success but leaves data missing, such as a blank column, and sends no alert. Once you know the answer, change the column name back.
Test 5 is a disconnected account. Disconnect or revoke the tool's connection to the sheet or email account, then submit a normal enquiry. Confirm the alert arrives through the channel you set up in lesson 7.2, Retries, fallback paths and alerts. Reconnect afterwards and, if your tool allows it, replay the failed run to check the enquiry wasn't lost.
After every test, check these four places and record what each one shows:
the run history the main sheet the log sheet the alert channel
A silent failure looks like success in the run history, missing data in the sheet and nothing in the alert channel. Getting no alert is the correct result when nothing actually failed, for example when a record was correctly routed to review. A wrong AI label on long input isn't a flow fault either. It belongs in the AI step's test set.
Mei Ling's shortened failure test record shows what this looks like in practice. The details are an invented example.
In test 1, their confirmation said "Hi there" because of a default they had set. The branch for a blank level sent the record to them for checking, and the log recorded "sent to review". No alert arrived, which was correct because nothing had failed, so the test passed.
In test 2, the flow ran, but the AI step labelled a long schedule question as "concern", and the log showed that label. That wasn't a flow fault. They noted it as a case for their 20-example test set from lesson 5.4, Test the AI step on 20 real examples.
In test 3, the phone number with letters went to review, as designed, and the emoji in the name came through fine. The test passed.
Test 4 found the gap. The tool reported success, wrote the enquiry with a blank phone column and sent no alert, which is a silent failure. Their fix was a check after the "add row" step that looks up the row just written and sends an alert if the phone field is empty when the form had a phone value. They also protected the sheet's header row, as lesson 4.1 suggested, which makes accidental column renames harder.
In test 5, the step failed with an authentication error and the error path ran. The alert arrived in their Telegram group within a minute, showing the step name and the record ID. After reconnecting, they replayed the run and the enquiry reached the sheet, so the test passed.
Mei Ling ended with four passes and one silent failure found and fixed. That fix would have caught a renamed column months before any parent noticed.
For every gap you find, fix it and rerun that test to confirm the fix works. Record the gap and the fix in your failure test record. Then add a line to the flow's documentation that describes the failure and what to do if it happens again. Module 8 turns these documentation notes into a proper runbook, so the more detail you write now, the less you'll have to reconstruct later.
When the tests are done, restore everything you broke and reconnect every connection. Clear the test entries from the sheet and the log, or mark them as tests.
You're finished when your failure test record shows five deliberate tests, each with the expected result, the actual result, whether an alert arrived and whether the log captured it. At least one gap must be fixed and retested, everything you broke must be restored and reconnected, and every test entry must be cleared or marked in the sheet and the log.
Pick a quiet hour, tell your alert recipients, and start with test 1.
Run five deliberate failure tests on your flow, record whether each raised an alert, and fix at least one gap.
Junxiong-WFG Organisation is an authorised representative of AIA Financial Advisers Private Limited (Reg. No. 201715016G).