WorkBuddy Scheduled Takeout Order Summaries, and I Fixed the Login Expiry Pitfall

During the morning prep gap, I scrolled onto a hands-on note from a long-time WorkBuddy user. The author said he'd built twenty-something automation flows, and the whole thing focused on the pitfalls he'd stepped in. One line had me nodding hard: the real blocker is login state. Websites' logins expire, and they trigger risk controls. Once a flow gets stuck there, it won't yell for you — it just fails silently. You only realize when you see a pile of backed-up data the next morning.

My little stir-fry shop lives off this. First, the timeline: I started using WorkBuddy at the end of July, so it's been a solid two months now. I wrote a piece before about permission settings for aggregating takeout bills — that one was about running it manually. This one is about how to make it run itself.

My flow's scenario is pretty unglamorous. Three takeout platforms, every night after closing I export the orders, reconcile them, and mainly check for amounts that deviate obviously. Before, I did it by hand — forty minutes minimum, and I still missed stuff.

The path is like this. Open WorkBuddy, click Automation in the left sidebar, then New Task in the top right. It gives you nine templates by default. I picked the one closest to "file organization," because my job is essentially reading a bunch of files in, sorting them, and spitting out a table.

After picking the template you specify the input directory. Here's a pitfall: the path must be absolute, like D:/stir-fry shop/takeout orders/2026-09. If you write a relative path it won't find it. That's where I tripped the first time — the error wasn't obvious either, the task just finished and nothing came out.

Then you write the prompt. At first I wanted to say everything in one go, and the output was wrong. Later I learned better: make it do one thing at a time. First categorize by platform, then merge into one table, then flag orders whose amount exceeds the prior seven-day average by twenty percent in a separate column. Written in three steps, it's way more accurate than one big paragraph.

I set the schedule for 11pm every night. One detail to flag: if the WorkBuddy client is closed, scheduled tasks won't trigger. It won't quietly work in the background, and a laptop with the lid shut asleep won't work either. My shop's old desktop just stays on — it's basically a fixed workstation.

On permissions, the shop has three people: me, my wife, and a helper. I put the WorkBuddy project directory under the user home directory, didn't stuff it into the system drive. I've seen people install apps into system directories and launch with a normal account, then they can't write data and get a pile of permission errors. For a non-technical guy like me, planning it right up front saves a lot of hassle.

I split permissions into three tiers. The raw receipt folder is writable only by me; my wife and the helper get read-only, to prevent a slip of the hand from changing source files. The summary table anyone can view. The prompt templates are locked to me, I don't let them edit — if they mess it up, the whole flow's output goes wrong. The helper only needs to get result notifications on his phone, doesn't even need to log in.

For daily ops I mainly watch three things. One, add a login check — this is the most valuable line in that note. I inserted a step at the start of the flow: first visit an address that requires login to see. If it detects a redirect to the login page, it sends me a notification, I log in manually once, so it won't fail silently. Two, do a manual test run first. When you create an automation task, don't set the schedule right away — click run-now once and check the output. If you set the schedule directly, chances are the output isn't what you want and you have to redo it. Third, only send messages on changes. I used to have it report daily, then realized it pinged me every day and I never looked. Now it only pushes when something's actually abnormal. Restraint here matters more than the feature itself.

I also tweaked model allocation while I was at it. Short tasks like field cleaning use a lightweight model; the complex merge-and-reconcile step uses a strong model. I didn't calculate exactly how much money it saves — I'm bad at math, I punched a calculator for ages and still couldn't figure it out. Anyway, supposedly for a flow running several months, using strong models for everything can cost several times more.

My environment is a Windows desktop. I haven't tried the Ubuntu setup, so it may not apply to everyone.

Yesterday that flow ran to completion on its own for the first time. In the morning I opened the computer and the table was already sitting in the folder.