Office automations tend to appear one at a time and without fanfare. A macro here, a scheduled script there, a no-code flow set up by a curious colleague. After a few years the office depends on a dozen invisible mechanisms, and nobody has an overall picture. The day one of them stops working, or the person who created it changes jobs, you discover how important it was. An automation inventory is the remedy, and it takes far less time than you might think.
The problem of invisible automations
A manual process is visible by nature: someone carries it out, and if they stop, the work piles up on their desk. An automatic process that stops often leaves no obvious trace. The report doesn't arrive and nobody notices for weeks; invoices are no longer filed and it comes to light at quarter end. The better an automation works, the more it is forgotten, and the more costly its failure becomes.
What to record for each automation
A one-page sheet per flow is enough. The format doesn't matter: a shared document, a spreadsheet, a page in the internal documentation. What matters is that it contains this information:
| Item | Example |
|---|---|
| Name and purpose | "Invoice archive: saves suppliers' PDF attachments to the Accounts folder" |
| Owner | The person who maintains it, plus a deputy |
| Where it runs | Accounts office PC, server, cloud platform |
| When it starts | Every day at 7:00, when a file arrives, by hand |
| Input and output | Invoices mailbox → shared folder Invoices/YYYY |
| Dependencies | Python and libraries, email account, network folder |
| Credentials | Which account it uses and where the password is kept (never the password itself) |
| How to tell it works | Log, notifications, folder to check |
| What to do if it stops | Checks and restart steps |
| Last review | Date and who did it |
The first rows take a few minutes to fill in. The last ones need a little more thought, and that is precisely where the value lies.
The recovery procedure
The "what to do if it stops" section must be written for someone who doesn't know the code. Something like this:
- Open the log file in the stated folder and look for lines containing
ERROR. - If the error concerns mailbox access, check that the app password hasn't been revoked.
- If the destination folder can't be reached, check the connection to the server.
- Rerun the script by hand using the shortcut on the desktop and check that new files appear.
- If the problem persists, contact the owner or the deputy.
Even when recovery still needs a technician, these steps let anyone tell whether the problem is trivial or serious, and give useful information to whoever steps in.
Hidden dependencies
The most frequent causes of failure lie not in the code but around it. In my work I find them almost always on the same list:
- changed or expired passwords for the account the automation runs under;
- personal accounts deactivated when someone leaves the company;
- folders renamed or moved by someone who didn't know a script used them;
- updates to the operating system, Office or a library that change some behaviour;
- external portals or services that change the format of their exports;
- replaced computers, with the automation left behind on the old one.
Recording dependencies on the sheet helps prevent most of these problems. Before renaming a shared folder or retiring a computer, just check the inventory.
Where to keep the code
Scripts shouldn't live only on the desktop of whoever wrote them. A shared folder with backups is the minimum; a version control system such as Git is the best choice, because it keeps the history of every change and lets you go back if a fix introduces a problem. For no-code flows, many platforms let you export the configuration to a file: keeping an up-to-date copy in the same place makes it possible to rebuild them.
Next to the code there should be a short text file explaining how to install what is needed to run it: Python version, required libraries, any external programs. A requirements.txt file listing the libraries covers most Python cases.
Regular reviews
Once or twice a year it is worth going through the inventory with a few questions: is this automation still needed? Is the owner still with the company? Are the credentials still valid and tied to a suitable account? Is the last successful run recent? Automations no longer needed should be switched off and archived, not left running out of inertia: every active flow is one more thing to maintain and, if it uses credentials, a potential security risk.
In short
- An inventory makes visible the automations the office depends on.
- For each flow record purpose, owner, schedule, dependencies and credentials.
- Write a recovery procedure that someone who doesn't know the code can follow.
- Keep code and configurations in a shared place, ideally under version control.
- Review the inventory regularly and switch off what is no longer needed.
