You will be able to add a log and approval steps that make every run traceable and every risky action checked.
A parent writes to the tuition centre in March. They sent an enquiry in January and never got a reply (both months are an invented example). Before you can answer, you need to find out a few things. Did the flow send a confirmation at all? If it did, which address did it go to? Did the AI step label the message correctly, and did the run follow the right branch?
If nothing records each run, your only option is the automation tool's history. You scroll back and match timestamps to work out what happened, and that history may only go back a limited time. With a log, the same question takes seconds to look up, and the parent has an answer within a minute. A human review checkpoint in the right place covers the other side. It stops an expensive mistake before it happens, so you don't have to explain it afterwards.
A log is a plain sheet, kept apart from your main data, where the flow adds one row on every run. It belongs to you, not to the automation tool, so it lasts for as long as you keep it.
Start by making a new sheet or tab just for the log. Keeping it separate means anyone working in the main sheet won't sort or overwrite it by mistake. Each row records five fields:
Time: when the run happened, in Singapore time. Record ID: the same ID from lesson 2.2, Data mapping: passing fields from one step to the next. Path taken: the route the run followed, for example "new enquiry, secondary branch" or "duplicate, updated existing row". AI label: if your flow has an AI step, the category it picked, for example "schedule" or "unsure". Result: how the run ended, for example "confirmation drafted", "sent to review" or "error at add row".
The step that writes to the log goes at the very end of every path in your flow. Put it on the error path from lesson 7.2, Retries, fallback paths and alerts, as well. If you leave it off, failed runs leave no row, and those are often the runs people ask about.
If your records contain personal data, the log will too, and it needs the same protection as the main sheet. Choose how long to keep rows, and delete older ones on a regular schedule so the sheet doesn't keep growing.
To answer the parent, search your main records for their email address and note the record ID. Then find that ID in the log. The row shows when the run happened, the path it followed, the AI label and the result, which is enough to reply.
Because every run adds a row, the log also gives you counts without any extra setup: runs per week, how often the AI step returns "unsure", and how many records go to review. You'll use these numbers in module 8.
Lesson 1.3, Know which work should stay manual, listed the actions that need a person to check them: sending anything to customers, moving money, and deleting data. These are hard or impossible to undo, so your flow should stop and wait for someone before it does any of them. Go through your flow, find these actions, and pick the one where a mistake would cost the most.
An approval step pauses the run at that point. The flow gets everything ready, such as a drafted reply or the payment details, shows it to a person and waits. If they approve, the run carries on. If they reject or edit it, the flow does what they decided.
How you build this depends on your tool. Some tools have an approval or wait step you can add. If yours doesn't, build one: write the item to a sheet that has an "approved" column, and set up a second flow that starts when someone fills in that column. If you set up the email drafts folder in lesson 5.3, Draft replies a person approves before sending, you already have an approval step, because nothing goes out until a person clicks send.
If checking each item takes five minutes, people will skip the step, rush it or quietly remove it. They approve quickly when the review is quick, so make approving one click and editing one click.
Put everything the reviewer needs on one screen: the original message, the drafted reply or proposed action, the AI label and the record ID. When reviewers have to open three tabs, they soon start approving without reading, and the checkpoint stops checking anything.
Mei Ling works from the email drafts folder. The AI's label sits in a note at the top of each draft, with the parent's original message quoted underneath, so she reads, adjusts and sends in under a minute. Arif approves invoices in a sheet tab filtered to "needs review", where the extracted figures sit in columns next to a link to the original PDF.
Once a checkpoint has run for a while and the outputs always look fine, you may want to remove it. Use the log to decide, not a feeling. Look back over several weeks of runs and check how often the reviewer changed the output, and by how much. If drafts with one label went out unchanged run after run for weeks, you could let that one label send without approval and keep the check on everything else. If the reviewer still changed even a few, keep the checkpoint. Never remove the checkpoint on payments, deletions or legal notices, however reliable the log looks, because mistakes there cost too much.
In the activity below you will add a log sheet to your flow with the five fields above, and one human approval step before the action in your flow that would cost the most if it went wrong.
Add a log sheet to your flow and one human approval step before the most consequential action.
Junxiong-WFG Organisation is an authorised representative of AIA Financial Advisers Private Limited (Reg. No. 201715016G).