You will be able to explain why automations sometimes run twice or not at all, and build in checks against both.
An automation can run twice for one enquiry, or not run at all, and both are normal problems. Neither shows up as an error, so you usually find out from the people affected. The fix is to build a check against each.
Mei Ling runs the centre and built its first enquiry flow. Two weeks after switching it on (her story and its numbers are an invented example), a parent called the centre, half amused and half annoyed, because the same confirmation email had arrived four times. Around the same time, a teacher passed on a report from a parent who had stopped him at the void deck: she had filled in the form and never heard back. When Mei Ling checked, the sheet had no row for her.
The most common cause of repeat emails is a trigger that watches for changes instead of for new items. Many spreadsheet triggers come in two kinds. A "new row" trigger fires when a row is added. An "updated row" trigger fires every time an existing row is edited, so each edit starts a fresh run of the flow and resends the confirmation. A teacher ticking "called back" counts as an edit, and so does someone correcting a typo in a phone number.
Mei Ling had set the flow to watch the sheet for updates, and the teacher had edited that parent's row three times. The original run plus three edit runs made four emails.
The fix is to trigger on the source event, the original thing the flow should react to. Here that is the new form response. Point the trigger at the form and leave the sheet out of the trigger completely.
If you must trigger on sheet changes, add two safeguards. First, a filter that lets the flow continue only when a specific column changes to a specific value. Second, a status column that the flow fills in once it has sent the confirmation. A second run then reaches the filter, sees the status already filled in, and stops.
The second cause of duplicates is people. Parents double-click the submit button, or submit, wonder whether it worked, and submit again an hour later. These are two genuine form responses with two different response IDs, and the flow will process both.
The same defence covers both kinds of duplicate: before adding a row, the flow looks for an existing one. Most tools have a "find row" or "lookup" action. Make it the first step after the trigger. Search the sheet for the incoming email address, or for the response ID if you are guarding against duplicates the flow itself caused.
Then branch on the result:
Nothing found: add a new row and send the normal confirmation. Match found: update the existing row, for example by adding the new message to a notes column and recording the latest timestamp, then either skip the confirmation or send a shorter "we already have your enquiry" note.
Email address is a good default field to match on for enquiries. Phone number also works, but only once it has been standardised, as shown in Lesson 2.3, Format dates, names and numbers on the way through. Name alone is a poor choice. Two parents can share a name, and one parent can type their name two different ways.
Decide how far back the lookup should search. A parent who enquired a year ago and is now asking about a younger child is probably making a new enquiry and should get their own row. The last 30 days is one example of a window; choose the one that suits your centre.
Lesson 2.1, Triggers, actions and the steps between them, explained that some triggers check for new data every few minutes instead of firing instantly. With a polling trigger there is a gap between the parent pressing submit and the confirmation arriving. How long the gap is depends on the tool and the plan you are on.
The gap affects what you can promise. If the form says the confirmation is instant and it arrives fifteen minutes later, the parent may think the form failed and submit again, which creates the duplicate you were trying to prevent. Find out whether your trigger polls on a schedule or fires instantly, then rewrite the thank-you page so it is true, for example "we will email you shortly to confirm". If the delay matters to the business, check whether your form and your automation tool support an instant trigger.
A missed run is harder to spot because there is nothing to see. The run did not fail. It never started, or it stopped at a filter it should have passed, and nobody was told.
That is what happened to the parent at the void deck. She had typed her email address with a space at the end, and the flow's filter for a valid email address rejected it without any warning. Mei Ling fixed it by adding a step that trims spaces before the filter.
The simplest check for missed runs is a weekly count. Compare the number of responses the form tool reports with the number of rows added to the sheet over the same period. If the form says 17 responses and the sheet has 16 rows, one run went missing, and you can find which one by matching response IDs between the two. If the sheet has more rows than the form has responses, something is creating duplicates. Either way you find out within a week, long before an angry parent calls.
To make the check easy to keep up, put a cell on a summary tab of the sheet that counts rows by week, and set a recurring calendar reminder for Monday mornings to compare it with the form tool's count. Lesson 7.2, Retries, fallback paths and alerts, shows how to have the flow send you this weekly summary automatically.
In the activity below, add a lookup step to your flow and test it the simple way: submit the form twice with the same email address and check that you end up with exactly one row and one confirmation.
Add a duplicate check to your flow and test it by submitting the same form twice with the same email.
Junxiong-WFG Organisation is an authorised representative of AIA Financial Advisers Private Limited (Reg. No. 201715016G).