What is automation logic?
Automation logic is the part of a workflow that decides what happens next. Taskade automations ship four flow steps for it, and every flow in this category is built from them:
- Branch — the run takes the first path whose condition is true. Up to seven paths plus a fallback, each with its own steps.
- Filter — the run stops here unless the condition holds.
- Loop — the steps inside run once for every item in a list.
- Delay — the run pauses, then picks up exactly where it left off.
A straight line of app-to-app steps can only do one thing per trigger. These four turn the same trigger into a workflow that routes, repeats, holds back and waits.
How does a branch decide which path to take?
A branch is a list of paths, checked top to bottom. The first path whose condition is true is the one that runs, and the others are skipped — so a branch is a decision, not a fan-out. Order matters: put the narrow condition ("order over $500", "plan is Business") above the catch-all, and set the last path's condition type to Fallback so no run falls through with nothing to do.
A single Branch step carries up to seven paths plus that fallback, and chaining a second Branch after the fallback path takes you past seven. The previews on this page draw two or three arms each, because that is what stays legible at this size — it is the diagram's limit, not the automation's.
Each path holds its own steps. That is what makes the pattern this category leans on possible: the expensive step lives inside one path only. Ask a named AI agent on the cases that need judgment, and file the routine ones as a plain task — the same automation, two very different amounts of work.
Why is a filtered run not a failure?
Most runs of a well-built automation should stop early. The email was a newsletter. The deal was under the review threshold. The alert was a warning, not an outage. That is the automation working, not breaking.
A Taskade filter ends the run cleanly. The run history records that it stopped at the filter, and nothing is marked as an error — so your failure list stays a real failure list instead of a wall of noise you learn to scroll past. Put the filter as early as you can: every step after it is work you no longer pay for on a quiet run.
Inside a loop the filter is even more useful. It does not abandon the whole run — it skips that one item and continues with the next, which is how you process forty rows and quietly pass over the six that are missing an email address.
How does a loop repeat a step for every item?
A loop takes a list — the line items on an order, the rows a search returned, the attendees on a calendar invite — and runs its body once per item, with the current item available to every step inside. One order becomes one task per product. One weekly search becomes one summary per result.
Keep the body small. A loop over forty rows runs its body forty times, so the steps inside are the ones worth trimming, and a filter in front of the loop is worth more than a filter anywhere else in the flow.
Why does a delay survive a restart?
A delay is not a timer sitting in the memory of whichever machine happened to start the run. The wait is durable — it is recorded by the automation engine, so if the machine running it restarts in the meantime, the run still resumes and the follow-up still goes out.
That is what makes multi-day work safe to automate: a three-day sales follow-up, a two-day escalation on a ticket nobody touched, a seven-day check-in after a cancellation, a drip that spreads onboarding over a fortnight. You are not asking a process to stay alive for a week. You are asking the engine to remember.
What can you build with it?
The 18 flows below are real triggers wired to real steps, and each one is built around the primitive that fits the job:
- Routing — orders, tickets, feedback, deals and subscriptions sent down the path their size or urgency deserves.
- Fan-out — one trigger, many records: per line item, per spreadsheet row, per attendee, per search result.
- Quiet by default — a filter in front of the work, so a normal day costs you nothing and the exceptions get the attention.
- Time — follow-ups, escalations, drips and cool-off windows measured in days rather than seconds.
Who is this automation logic for?
Anyone whose workflow already has an "if" in it. Support teams that treat an outage differently from a billing question. Sales teams that want the big deal reviewed and the small one filed. Operations teams processing a list rather than a single record. And any team whose current answer to "what happens on day three?" is a reminder in someone's head.
How do you set one up?
- Open the Automations tab in your workspace and add a trigger.
- Add the plain actions first, and get the simple version running end to end.
- Add a Filter early, so the quiet runs stop before they cost anything.
- Add a Branch where the work genuinely differs, and put the heavier step — the agent, the notification, the escalation — inside the path that needs it.
- Add a Loop where you are handling a list, and a Delay where time has to pass.
- Or describe the outcome at Taskade Genesis and let it wire the trigger, the steps and the logic for you.
Where should you go next?
- All automation categories — the full index.
- AI agent automation — the named agents that sit inside these branches and loops.
- Automation workflows, automated processes and automation actions — the same engine, framed by shape, by scope and by step.
- Taskade connects to 100+ apps in both directions, so any of these paths can end in the tool your team already lives in.
