With WorkBuddy, don't let it think—just weld the entry point shut

I've been using tools like WorkBuddy for two months, and my biggest takeaway is: the narrower its scope of activity, the better it works. Don't expect it to be good at planning. For single-person use, you narrow the instructions; for multi-person shared use, you narrow the permissions.

Every month there's still that batch of spreadsheets from different sources that has to be merged. Everyone formats them their own way, and in the end it has to become one presentable thing. I hand this part to WorkBuddy, macOS desktop version—Windows should be about the same, but it may not suit everyone. The workflow itself isn't complicated. Create monthly-in and monthly-out on the hard drive, drag all the source sheets into in, unify the filenames to source-date.xlsx, with hyphens, no spaces and no Chinese parentheses. Open WorkBuddy, click Workflow in the left sidebar, click New in the top right, choose Folder batch processing, and select in and out as the input and output directories respectively. In the task instruction box, write it like a shell script, three lines: which columns to read, write the column names in full; how to handle duplicates, dedupe by order number, keep the one with the latest date; what the output filename is. In the workflow settings, turn off Allow automatic step supplementation, and keep Confirm before running. This whole thing takes about twelve minutes to run, five minutes of human time, and the rest of the time it's running.

These are the premises for single-person use. Once you share a workspace, problems come up.

Three of us share one workspace. When the workflow was first built, I thought it was convenient, so I set the permission to Editable, thinking whoever spots a problem can fix it. As a result, the second month, someone thought the dedupe line was "too rigid" and casually changed it to dedupe by entire row, and the output directly had a batch of duplicate orders. That day we reconciled accounts until evening, and it took ages to locate that the instruction had been changed. Since then I've set the workflow to Only creator can edit, and the other two are Can run. They can click run, can see the output, but can't change the instructions. Production flows and experimental flows have to be separate—it has nothing to do with trust. If you want to change the template, copy the workflow, get it running after the change, then switch over; don't directly touch the one in use.

On permissions, my current approach is to split it into several layers.

First, the workflow itself. The production one only allows the creator to edit; everyone else is Can run. Runners can trigger it and see results, but can't see the "edit instructions" entry. If someone needs to tweak parameters, copy a temporary workflow for them, name it with -test, and after running and checking the numbers, decide whether to merge it back into production. That way, if a slip of the hand deletes the dedupe line, only the copy is affected.

On directories, monthly-in and monthly-out must be separate, and different drives are even better.

I once cut corners and set out as a subdirectory of in. The second run read the previous output as input too, doubling the data, and it took half an hour to find out. After sharing, this problem is even more dangerous: if others add sheets to in, and out is also inside it, the next run will eat the historical output again. Now in only holds source sheets, out creates subdirectories by batch, and historical output isn't overwritten.

I keep the pre-run confirmation because the output will overwrite files with the same name in the out directory. Before running, glance at the step list, confirm nothing weird has been added, and confirm the instructions are still those three lines. In a shared workspace this step can't be skipped—you never know what the last person clicked.

Versions also need managing. Templates always get changed—fields added, definitions changed—and historical output won't match. My approach is to put a version number in the workflow name, like Monthly merge-v3, don't delete the old version, and change its permission to read-only. Every time you change the template, copy first then change; after it runs, lock the old version and give the new one to runners. The output directory also carries date and version, so when you look back at historical data, you can match which workflow version was used at the time. Write the change log in the workflow description—who changed it, what changed, why—three lines is enough; don't rely on chat logs.

There are also two pitfalls related to permission boundaries. Sheets with spaces in the filename get skipped outright, and the log doesn't report an error either—I only found out later by checking row counts. So now before source sheets go into in, filename standardization is a hard requirement; whoever drags it in is responsible for renaming it. The other is that it often misses the Remarks column, the same problem I had with other tools before; the output has to be checked yourself. This step can't be handed to run permission—it can only be left to the final checker.

When a newcomer joins the workspace, I only give Can run, not edit. If they need to see historical output, give view permission. At handover, give a copy of the workflow, not edit rights to the production flow. Sounds a bit strict, but in a shared workspace, once someone runs it wrong, nobody dares use the output numbers—that's way more expensive than the tool subscription fee.

I now keep versions for all template changes: old version read-only, new version as a separate one, switch after it runs. The shared workspace permissions are split into these layers, and for now that's enough.