You will be able to write a short runbook that lets a colleague understand, fix or switch off an automation.
Any automation that only its builder understands puts the business at risk, no matter how good the build is. You deal with that risk by writing a runbook, a short document that tells someone else how the automation works, how to spot that it has gone wrong, and what to do next.
Arif built the invoice flow at his office and still owns it. In December he took two weeks' leave (the dates in his story are made up for illustration). On the third day of his leave, the flow stopped logging invoices. The boss only found out when a supplier chased an unpaid bill. Nobody in the office knew the flow in any detail. They did not know which account it used, where its log was kept, or whether they could safely switch it off. In the end someone messaged Arif, and he fixed it on his phone at a hawker centre in Penang. He came home determined to write it all down.
When you write yours, picture a colleague who did not build the flow and may not know the automation tool well. Aim for one page, two at the very most.
Open with the basics in a fixed order, so a reader always knows where to look. Start with the purpose, in one or two sentences: what the flow does and why the business needs it. Next comes the owner, meaning who built it, who looks after it today, and who to call when that person is away. Then describe the trigger, the event that starts a run, in everyday words. An email landing in invoices@ is a typical example. After that, list every app the flow connects to and the account each connection uses. Finish with where everything lives: the automation tool, the flow's name inside it, the main sheet, the log, the review list and the folders.
Arif's version starts this way. The flow exists to log every supplier invoice sent to invoices@ into the Invoices sheet and file the PDF, so spending can be seen by supplier. Arif is the owner and the office manager is his backup. A run starts whenever an email with an attachment reaches invoices@.
Write account details precisely. "Connected through the invoices@ account" tells your colleague which login to reach for when a connection has to be redone. Leave passwords out of the document altogether. Note instead where they are stored, such as the company's password manager, and which people can get into it.
The failure list is the part your colleague will use most. Build it from three places. Lesson 7.1 named the common reasons flows fail. Lesson 7.4, Break your own flow on purpose, left you with a record of how your own flow breaks. Your log shows what has really gone wrong so far.
Write each entry as a symptom your colleague can see, followed by a fix they can carry out. Arif's runbook has two entries like this.
In the first, the alert reports that authentication failed on the sheet step. The usual cause is a change to the invoices@ password. To fix it, open the automation tool, go to connections, reconnect the sheet with the invoices@ account, and replay the runs that failed.
In the second, invoices show up in the sheet with no amounts. Someone has probably renamed a column. The fix is to compare the header row with the column names listed in the runbook and put back whichever one was changed.
That second fix depends on the list being there, so write down every column name the flow relies on and state that none of them may be renamed. Also describe what the alert looks like and where it turns up, so your colleague knows it when they see it.
There are times when someone has to stop the flow: it is sending the wrong emails, it is mangling one supplier's invoices, or one of the connected apps is acting oddly. Give the exact clicks for turning the flow off in your tool. Then answer two questions in writing. Does switching off lose anything that was halfway through? And will runs that arrive while the flow is off be picked up later, or will they be missed? Tools differ on this, so try it yourself before you put the answer down.
The business still has to run while the automation is off, so describe the manual workaround. In Arif's runbook it says that invoices keep arriving at invoices@. Once a day, someone opens that inbox, saves each PDF to the Invoices folder, and adds a row to the sheet with the supplier, date, number and total, marked "entered by hand". Mei Ling looks after an enquiry flow. Her by-hand routine is the shortened version she worked out in lesson 1.2, Fix the process before you automate it, set out as a short checklist.
Close this part with restart instructions: how to turn the flow back on, then what to check. That usually means replaying any runs that were missed and making sure the next real run lands in the sheet.
Nobody will find a runbook in the middle of a problem if it sits only inside the automation tool or in someone's personal drive. Put it wherever your team already keeps shared documents, whether that is a shared drive, a wiki or a project folder. Give it a title people would actually type into a search box, for example "Invoice automation runbook".
Then add links to it in the places people go when something breaks. Those are the alert message you set up in lesson 7.2, the first row or description of the main sheet, and the flow's description in the tool if your tool has that field.
Every change you make to the flow means a matching change to the runbook. A runbook that still describes last year's version does more harm than having none, because your colleagues will follow it.
In the activity below, write a one-page runbook for your enquiry or invoice flow. Then hand it to a colleague and ask them to read it and put one question to you. Whatever they ask about is the part your runbook explains least well.
Write a one-page runbook for your enquiry or invoice flow and ask a colleague to read it and ask one question.
Junxiong-WFG Organisation is an authorised representative of AIA Financial Advisers Private Limited (Reg. No. 201715016G).