Handing repetitive work to an automation
The automation that runs every day and saves four minutes beats the clever one that runs monthly. Start smaller than feels worthwhile.
Automation is a visual, node-based builder: you connect a trigger to one or more actions, arrange the nodes on a grid, and either run the flow on demand or let the trigger fire it. Saving a flow as a template means the next similar one starts from something rather than nothing.
The mechanics take twenty minutes to learn. Choosing what to automate takes longer, and getting that wrong is why most people's automation folders contain four flows they no longer trust.
What is actually worth automating
The instinct is to automate the annoying thing. The annoying thing is usually annoying because it is rare and requires thought, which makes it the worst candidate.
What pays off is the opposite: small, frequent and boring. Multiply the minutes by the frequency and the answer becomes obvious.
- Four minutes, every day → 16 hours a year. Automate it.
- Two hours, twice a year → four hours. Do it by hand and keep your afternoon.
The other filter is judgement. If the task requires deciding something — is this lead worth chasing, is this bug urgent — automation can prepare the decision but should not make it. A flow that assigns and notifies is useful; a flow that closes tickets it judged unimportant will lose you something real, quietly, for months.
Make the first one disposable
Your first automation should be one that nobody notices if it stops. Not the invoice run. Something like: when a card moves to done, post a line in the team channel.
Two reasons. You will get the trigger wrong the first time — everybody does — and the cost of that should be a confused colleague, not a missed payment. And a flow you can watch running for a week teaches you more about how triggers actually fire than any amount of reading.
Once it has run for a week without surprising you, build the one that matters.
The loop, which is the one real danger
This deserves its own section because it is the mistake that costs money rather than time.
A flow triggered by "a record changes" that itself changes a record has just triggered itself. It will keep going. If any step in that flow calls an AI action, every iteration draws from your token balance, and you find out the next morning.
Three habits prevent it entirely:
- Never let a flow write to what triggers it. If it must, narrow the trigger — a specific field, a specific status transition — so the write does not match the trigger condition.
- Run on demand first. Automation lets you execute a flow manually. Do that three times and read what happened before you attach a trigger.
- Check the run count the next day. Automation shows how many times each flow has executed. A flow with a four-figure count after two days is a loop, and that number is the fastest way to find it.
Flows have owners, and owners leave
Every flow shows who created it, and that field matters more than it looks.
An automation built by someone who has left the company keeps running. But anything inside it that depended on their access — a project they could see, a connection they authorised — starts failing, and it fails quietly, because a flow that errors does not send anyone an email.
Add it to your offboarding routine: sort automations by owner, and for anyone leaving, either reassign or switch off. Ten minutes on the day beats a fortnight of "why did nobody get notified".
Draw it before you build it
For anything with more than three steps, open Flowchart first and sketch it. This sounds like an extra step and it removes one.
A diagram makes the branches visible — the case where the field is empty, the case where the person is not in the workspace, the case where the previous step returned nothing. Those branches are what break automations in week three, and they are much easier to see in a drawing than in a node graph you are actively assembling.
The diagram also survives the person who built it. Six months later, "what does this flow do" is a question with an answer.
Questions people actually ask
How do I know if a flow is stuck in a loop?
Check the run count. Automation shows executions per flow, and a four-figure number two days after you enabled something is a loop. The cause is almost always a flow that writes to the same records that trigger it.
Do automations cost AI tokens?
Only if a step calls an AI action. Moving cards, sending notifications and updating fields cost nothing. That is exactly why a loop containing an AI step is the expensive kind of mistake.
What happens to automations when their creator leaves?
They keep running, but anything depending on that person's access starts failing silently. Sort by owner during offboarding and reassign or disable — a failing flow does not notify anyone.
Can I test a flow before it goes live?
Yes. Run it on demand rather than attaching a trigger, do that a few times, and read what actually happened. Every automation should earn its trigger.
