You will build and switch on a working enquiry flow from form submission to confirmation to a follow-up reminder.
Before you build anything, open your automation tool and check that the enquiry flow is switched off. Leave it off until every test has passed. Then put the pieces you already have side by side: the flow diagram from lesson 2.4, the tool from lesson 3.4, the sheet from lesson 4.1, the confirmation email from lesson 4.2 and the duplicate check from lesson 4.3.
Each of those pieces works on its own. A common failure at this stage is to stop there, with separate pieces and a flow that has only ever run on tidy test data. Then the flow is switched on, the first odd enquiry breaks it, and people stop trusting the whole system. Your job now is to join the pieces, run a proper set of tests, and switch the flow on only when the results match what you expected.
A new enquiry from a form triggers three actions. First, the flow writes the enquiry to the sheet with an ID, a timestamp and the form fields. Second, it sends a confirmation email to the person who enquired. Third, it creates a follow-up task or reminder, with a due date, for whoever needs to respond.
It also has to handle the awkward cases. It should ignore test entries and spam. A repeat enquiry from the same email address should not create a second row or send a second confirmation. Blank fields should not produce a broken email.
If the task you chose in module 1 is not an enquiry flow, adapt the brief. The same pattern of trigger, record, confirmation and follow-up fits bookings, orders, job applications and support requests.
Start from the trigger. Connect the form and pull in a realistic sample response with every field filled in, as lesson 2.2 recommended, so every later step has realistic data to map.
Next, add the filter for test entries and spam. A simple rule works for most small forms: stop the run if the email contains your own domain, if a field you use for testing contains the word "test", or if the message is empty. Mei Ling, an example learner who runs an education centre teaching several levels and gets her enquiries from parents, added one more rule: stop if the message contains a web link. None of her real parents had ever included one, and most of her spam did.
After the filter, add a lookup for an existing row with the same email address and branch on the result, as lesson 4.3 described. This gives you two branches, the new-record path and the existing-record path. On the new-record path, add the row with all fields formatted, then send the confirmation. On the existing-record path, update the row and skip or shorten the confirmation.
Then create the follow-up task. Most task apps, calendars and chat tools can do this. Give the task a clear title that includes the person's name and the record ID, and calculate the due date from the timestamp, such as two working days later.
Last, fill in a status column on the sheet that records that the confirmation went out, so anyone reading the sheet can see where each record stands.
Keep the flow switched off the whole time you are building. Most tools let you test individual steps or run the whole flow manually, and that is enough while you build.
Write all ten test enquiries before you start testing, so you are not inventing them as you go. Use email addresses you control. Submit them one at a time. For each one, write down the result you expect before you look at what actually happened.
Record everything in a test log, a simple table with columns for the test number, what you submitted, what you expected, what happened in the sheet, what happened in the email, what happened with the follow-up, and pass or fail.
Check every row the flow wrote in the sheet. Read every confirmation email on a phone as well as a computer. Check every follow-up task and its due date. Go through them slowly, because the failures that matter tend to be small: a timestamp several hours out, a blank where the level should be, a due date that falls on a Sunday.
When something fails, fix it and then rerun all ten tests, including the ones that passed before, because a fix in one place can break another.
Mei Ling's ten cases were:
four normal enquiries, one for each level the centre teaches, with names in different formats one duplicate using the same email as the first test, sent a few minutes later with a different message one with the name left blank one with a phone number typed with spaces and the country code one staff test entry from the centre's own domain one spam-style message containing a web link one with a very long message of several paragraphs copied in
Her first run passed eight of ten. The duplicate created a second row because her lookup searched the email column before the email had been trimmed of a trailing space. The long message was cut short in the confirmation email because she had mapped the message into the email body. She did not need it there, so she removed it. She fixed both problems, reran all ten tests, and got ten passes.
The flow is ready when you have ten cases, including a duplicate and at least one missing field, and all of them pass on the final run. Switch it on then.
Delete or mark the test rows in the sheet and the test tasks so they are not mixed up with real enquiries. As a final check, send one more real-looking enquiry through the live flow and watch it arrive.
Set aside an hour, write your ten test cases first, and then open your tool and start with the trigger.
Build the full enquiry flow in your chosen tool, run ten test enquiries through it, and record the results in a test log.
Junxiong-WFG Organisation is an authorised representative of AIA Financial Advisers Private Limited (Reg. No. 201715016G).