Almost every automation example you'll find is written as two parts. When this happens, do that. New form entry, create a record. Ticket arrives, route it. That version works beautifully in a demo, because in a demo the input arrives in exactly the shape the example assumed.
Then you switch it on against real mail, and on about day three it files your biggest customer's outage under Newsletters. Not because the automation broke. Because nobody ever wrote down how it was supposed to tell an outage from a mailing list, or what it should do when it couldn't.
So the twelve below are written out in full, four parts each, including the test that decides whether a given case is one the rule should touch and what happens when that test gets it wrong.
What counts as a workflow automation example
A workflow automation example is one rule: a single event that wakes it up, a test that decides whether this case qualifies, one job it does, and a defined outcome for when the test gets it wrong. That's the whole unit. It isn't a project, it doesn't need a platform, and most of the useful ones take about ten minutes to set up in software you already pay for.
That's worth separating from the level above it, because the two get sold as the same thing. A whole process, the kind with hand-offs, approvals and a person waiting at each end, is a different job with a different failure mode, and we keep those on business process automation examples along with the question of which process to tackle first. This page is the level below: the individual rules those processes are built out of, and how to write one that doesn't embarrass you.
Two words you'll meet repeatedly below. A connector is a paid service that watches one system for something happening and writes the result into another; it holds no data of its own and does no work of its own, which is why it can only reach systems that expose an interface for it. A scheduled job is anything that wakes up on a clock rather than on an event, which turns out to matter a lot. Campaign and sequence automation, the marketing side of this, works differently enough that it belongs with email automation best practices rather than here.
The four parts of a rule, and the two that get left out
| Part | The question it answers | What happens if you skip it |
|---|---|---|
| Trigger | What wakes this rule up? | Nothing fires, and you're back to remembering to do it yourself. |
| Condition | Is this case one the rule should touch at all? | It fires on everything that vaguely resembles the trigger, and you stop trusting it inside a week. |
| Action | What does it actually do? | The rule watches and changes nothing, which is a notification about itself at best. |
| Fallback | What happens when the condition got it wrong, and how does a human find out? | The misses are invisible. The rule looks fine right up until a customer asks why nobody answered. |
The first and third parts are the ones every example publishes. The pattern isn't an accident: a vendor's example exists to show you that their product can connect A to B, and both the condition and the fallback are places where your judgement does the work rather than their software. They're the two parts with nothing to sell.
They're also the two that decide whether you keep the rule. A sloppy condition doesn't fail loudly, it just becomes something people route around, and six months later somebody says "oh, we ignore that label."
At a glance: 12 rules and where each one lives
| What starts it | The condition | What it does | When the condition is wrong | Where you can build it |
|---|---|---|---|---|
| Mail lands at the shared address | What the message is actually about | Labels it and puts a named person on it | Unplaceable mail goes to a person, never to a folder | Mail filter, or a shared inbox tool |
| Mail lands at the shared address | Human sender, first message of the thread, outside the window where someone would have replied anyway | Sends one acknowledgement with a timeframe | Irreversible, so what it promised is written on the thread for whoever picks it up | Mail filter plus a template |
| Mail lands at the shared address | Headers say a machine sent it | Files it out of the human queue | Someone reads that label once a week | Mail filter or inbox rule |
| An approval request is submitted | The amount against a threshold, and who submitted it | Sends it up a level instead of to the usual approver | Unroutable requests wait in a named queue with their age showing | Your spend tool's own rules |
| An expense or invoice arrives | Category, amount and attachments against written policy | Flags it for a human before anyone approves | Flag only, never an automatic rejection | Your spend tool's own rules |
| An invoice arrives | Same vendor and amount inside 30 days | Holds it and asks, instead of paying it | A held invoice ages visibly and is somebody's job | Accounting rules, or a connector |
| A record is created: an enquiry, a lead, a signed quote | The field that decides ownership is filled in | Creates a task, or routes the lead, with a person's name on it | No owner means a person by default, not a shared queue | A connector |
| A start date is set | Date in the future, role populated | Opens the provisioning checklist | The day before, anything unticked goes to a human | Your HR system's own workflow |
| A status changes | It's a transition someone is waiting on | Notifies exactly those people, nobody else | Everything filtered out still lands in a scannable digest | Chat workflow builder |
| A scheduled check | Thread open, last message from outside, 24 working hours passed | Surfaces it to a named person with its age | The check reports that it ran, not just what it found | Shared inbox tool, or a connector on a clock |
| A scheduled check | Past day 30, still unpaid, not disputed or on an agreed plan | Sends the reminder and tells the relationship owner | Irreversible, so anything borderline goes to a person to send by hand | Accounting rules |
| A set day each week | Open, and nothing has changed since the last run | Puts it on one list a human reads | The list goes to someone who can actually close things | Scheduled report, or a connector on a clock |
Rules for the inbound mailbox
1. Route inbound mail by what it's about
Trigger: A message arrives at the shared address. Condition: What the message is about. Not who sent it, which is what most filters actually test, and not a keyword in the subject, which is the same test in a disguise. Action: Apply a label for the category and assign one named person. Fallback: Anything the condition can't place goes to a person, not to a folder called Unsorted.
This is where sender-and-keyword filters run out of road fastest, because "urgent" in a subject line is as often marketing as it is an outage. Sorting inbound mail by what it is before anyone reads it is its own discipline, and how much ambiguity your condition can absorb is mostly a question of what makes the decision. A shared inbox tool like TriageFlow classifies with a model rather than a keyword list, which is why it can place the outage the filter would have filed under Newsletters.
This is still one rule, though, not a support operation. If you're building the whole inbound side, the order to do the support side in is a bigger job than this page covers.
2. Acknowledge with an expectation you can keep
Trigger: A message arrives at the shared address. Condition: It's a human, it's the first message of this thread (which needs a per-thread marker, or the customer who sends three messages in ten minutes gets three replies), and you're outside the window where somebody would have answered anyway. Action: One reply with a specific timeframe. "Today or tomorrow" beats "as soon as possible", which everybody reads as "never". Fallback: Nothing sent to a customer can be recalled, so promise a timeframe you can hold on your worst day, and have the rule note on the thread what it promised: whoever picks the thread up then inherits the commitment instead of contradicting it.
The condition is doing all the work here. Get it wrong and you auto-reply to your own auto-replies, which is a loop that has embarrassed better teams than yours. If you're writing the wording rather than the rule, what the acknowledgement should actually say covers that side.
3. Keep machine mail out of the human queue
Trigger: A message arrives at the shared address. Condition: The headers say a machine sent it. Bulk mail, automated submissions and delivery notifications all announce themselves in headers, which is a far more reliable test than the words in the subject. Action: Label it and archive it out of the working queue. Fallback: Someone opens that label once a week. Ten seconds, and it's the only thing standing between you and a real message that looked like a receipt.
Small rule, disproportionate effect. A queue that's mostly notifications trains people to skim, and skimming is how the real message gets missed.
Rules for approvals and money
Each of these three is one rule sitting inside a process that runs end to end. Spend approval as a whole process, with the hand-offs and the after-launch cost, is covered at the process level. What follows is just the rules.
4. Route an approval by amount
Trigger: Someone submits a request. Condition: The amount, against a threshold, plus who submitted it. Both, because a small amount from a new starter and a small amount from your finance lead aren't the same risk. Action: Under the threshold, straight to the usual approver. Over it, up a level. Fallback: Anything that can't be routed sits in a pending queue with a name attached and an age, so it's visibly waiting rather than silently gone.
The temptation is to add a third and fourth tier. Resist it until the first two have run for a month, because every tier is another place for a request to get stuck behind one person's holiday.
5. Flag out-of-policy spend before anyone approves it
Trigger: An expense or invoice arrives. Condition: Category, amount and attachments against your actual written policy. If the policy isn't written down, the condition can't be either, and that's the real blocker on this one. Action: Add the flag and the reason, and put it in front of the approver rather than behind them. Fallback: Never auto-reject. A flag a human overrules in four seconds is useful, an automatic rejection of a legitimate claim costs you an afternoon and some goodwill.
What you gain here is timing. The approver sees the problem while they still have a decision to make, rather than a month later during a reconciliation.
6. Catch the duplicate invoice
Trigger: An invoice arrives. Condition: Same vendor, same amount, inside a window. Thirty days catches the honest resend, the duplicated entry, and the invoice that was never owed in the first place. Action: Hold it and ask, don't pay it. This rule is itself the approval step that the irreversible action, paying, needs in front of it. Fallback: The wrong answer here is a legitimate second invoice, for the same amount, that gets held. So the held pile has to be somebody's actual job, with the age of each hold visible, or your fraud control quietly turns into a late-payment generator. A hold nobody looks at is worse than no rule, because everyone assumes it's being handled.
Rules for handing work between people
All three of these sit inside processes that the process-level page walks end to end, onboarding and record-syncing among them. Here they're the individual rules, with the parts that decide whether they hold.
7. A new record or lead becomes a task with an owner's name on it
Trigger: A record is created in one system. A form submission, an enquiry from the website, a new lead, a signed quote. Condition: The field that decides ownership is actually filled in, and the record isn't a test or a duplicate of one from five minutes ago. Firing on creation alone is the most common way these rules generate a pile of ownerless tasks. Action: Create the task in the other system with the owner set, a due date, and a link back to the original record so nobody has to go hunting for context. This is the same rule as lead routing, incidentally: a lead is a record with an owner problem. Fallback: If ownership can't be determined, the task goes to a person by default, never to a shared queue. A queue that nobody owns is a queue nobody reads.
This is the rule that most often needs a connector, because the two ends are different products. Check before you buy that both ends actually expose an interface: no amount of no-code interface makes a system without one reachable.
8. A signed start date opens a provisioning checklist
Trigger: A start date is set on a record. Condition: The date is in the future and the role is populated, because the role decides which items the checklist even contains. Action: Open the checklist, assign each item, and set the dates backwards from day one. Fallback: A check the day before the start date that looks at what's still unticked and tells a human, not a channel. Manual onboarding misses steps unpredictably, and the cost of a miss here shows up as somebody's first morning spent waiting for a laptop.
9. A status change notifies exactly the people it concerns
Trigger: A status field changes. Condition: It's a transition someone is actually waiting on. "Any change" is not a condition, it's a firehose, and a firehose gets muted within about a week, which leaves you worse off than having no rule at all. Action: Notify those people, in the place they already work. Fallback: Everything that didn't meet the condition still happened, so it belongs in a digest somebody can scan rather than nowhere.
This is the rule most often built badly, and the failure is silent: nobody tells you they muted the channel.
Rules that fire when something does not happen
Almost every automation example you'll read fires on an event. The rules that quietly save a small team are often the opposite: they fire because something didn't happen. Nobody replied, nothing got paid, nothing moved on an open item for a fortnight.
These are harder to build, and it's worth knowing why before you try. An event rule waits to be told. An absence rule needs a clock of its own, something that wakes up on a schedule and asks a question about current state. Mail filters can't do this at all, because a filter only ever runs when a message arrives. You need a tool that tracks thread state, or a scheduled job.
10. Nobody replied in 24 working hours
Trigger: A scheduled check, not an event. Condition: The thread is still open, the last message came from outside, and 24 working hours have passed. Calendar hours will page someone about a Saturday morning email on Monday, by which point it's stale and the alert is just noise. Action: Surface it to a named person with the age on it. Fallback: If the check itself doesn't run, nothing happens and nobody knows, which is the nastiest failure mode on this page. So the rule reports both halves: here's what's overdue, and here's the fact that I ran. A silent absence rule is indistinguishable from a working one.
11. Nothing paid by day 30 (the collections rule)
Trigger: A scheduled check, daily. Day 30 doesn't announce itself. Condition: Past day 30, still unpaid, and not disputed or on an agreed plan. That last part is what stops the rule chasing the one customer your account manager is mid-negotiation with, and it means the rule has to read an exclusion list a human maintains. Action: Send the reminder, and tell whoever owns the relationship that it went. Fallback: A dunning email can't be unsent, so this one gets an approval step rather than an alert: anything the condition can't clear cleanly, a partial payment, a recent inbound message on the account, a customer flagged as being in conversation, goes to a person to send by hand. The rule handles the unambiguous majority, which is most of them, and the awkward few are exactly the ones a human should be sending anyway.
12. No movement on an open thread since Tuesday
Trigger: A set day each week. Condition: Open, and nothing has changed since the last run. Not "old": plenty of things are legitimately old and fine. Action: One list, in one place, that a human reads. Fallback: The list goes to a person with the authority to close things, otherwise it becomes a weekly report everyone receives and nobody acts on.
What your current subscriptions will and will not do
Most of these twelve can be built in what you already pay for. That layer is bigger than the product lists admit, and it has published ceilings that the lists don't mention either.
Gmail filters can, in Google's own words, "send email to a label, or archive, delete, star, or automatically forward your mail." Two documented behaviours will bite you if you don't know them. Google states that "when you create a filter to forward messages, only new messages will be affected", so a filter you build today won't reach back over the backlog. And a reply is only filtered if it independently matches the same search criteria, which means a filter is not a thread-level rule at all. It's a message-level one, every time, so any rule of yours that reasons about the state of a whole conversation needs to live somewhere else.
Exchange Online inbox rules are limited by size rather than count, which catches most people out. Microsoft documents that inbox rules are "limited to 256 KB total for all rules" in a mailbox, and states plainly that "there isn't a maximum number of rules that users can create." Don't plan on asking your admin for more, either: the same page says "you can't increase the amount of space that's allocated to store Inbox rules in Exchange Online, but you can decrease it", so 256 KB is both the default and the ceiling and the adjustable range only runs downward. The quota counts only enabled rules, so disabling one frees its space. Two more details matter for anything you build: rules "are run from top to bottom in the order in which they appear", so order is part of your logic whether you meant it to be or not, and on forwarding rules, "if you add more addresses than are allowed, your forwarding rule won't work."
Outlook rules carry the single most common reason a team thinks its automation is broken. Microsoft says that "certain rules will only run when Outlook is on", and separately that "some rules created in classic Outlook can't be processed by new Outlook because they are client-side rules." A rule that depends on one person's laptop being awake is not a team automation, and nothing in the interface tells you which kind you just built.
Slack Workflow Builder handles the notify-and-hand-off rules well, with two ceilings worth knowing. Slack documents that "you can add up to 100 steps to a workflow", which is generous for anything on this page. The one that catches people is the downgrade: Slack states that on the free version, "existing workflows will stop working when you downgrade, and you won't be able to create new ones". If a plan change is anywhere in your near future, don't put a rule you depend on there.
When you do hit these walls, the next question is what to buy and in what order, and that's a genuinely separate decision: what you would actually be buying, and in what order works through it, including why the price you're quoted is per something different in every case.
One thing we won't give you is a figure for what any of this saves. Every number on this topic we could find traces back to a vendor, a study a vendor paid for, or an agency quoting its own rate card, and there's no honest way to launder those into a benchmark. The numbers on this page are the documented ones: 256 KB, 100 steps, top to bottom.
Writing the fallback half
The fallback is just three questions, and they take about a minute per rule.
Can this action be undone? Labels, notifications and drafts can, so an alert is enough. Payments, deletions and anything a customer receives can't, so those need the approval step built into the rule. It's the one distinction worth being strict about.
Where does a wrong answer show up? It has to appear on a screen a human is already looking at. A log file nobody opens isn't a fallback, and neither is an email to an address that goes to everyone. The best version is usually a label or a queue that sits next to the work, so the miss is visible without anyone going to look for it.
Who is that human, by name? Not a team, not a channel. The rule that catches an out-of-policy expense is only as good as the person who reads the flag, and "the ops team" is not a person.
Program-level monitoring, the dashboards-and-alerting question for a whole stack of automations, is a bigger job and lives with the buying decision. What every single rule needs, on its own, is the three answers above written down somewhere you'll find them in six months. (For the wider case, what automating a whole process gets you and what it costs you to keep, the process-level page has a section on exactly that.)
Frequently asked questions
What is an example of workflow automation?
A complete one, in four parts: an expense report is submitted (trigger), the amount is over your sign-off threshold and the submitter isn't already an approver (condition), so it routes to the next level up instead of the usual approver (action), and anything it can't route waits in a named queue with its age visible rather than disappearing (fallback). Written out like that, it takes about ten minutes to build in whatever tool already holds the expenses.
What is the difference between workflow automation and process automation?
A workflow automation is one rule with one trigger. Process automation is the whole path a piece of work takes, usually several rules with hand-offs between them and at least one human approval in the middle. Reimbursing an expense is a process; routing the approval is one rule inside it.
What are the four types of workflows?
The labels you'll see are sequential, parallel, state-machine and rule-driven, describing the shape: one step after another, several at once, something that moves between defined states, or a set of independent rules. Useful vocabulary. In practice the distinction that changes what you actually build is a different one, and it's whether a human has to say yes before the action happens, because that decides how much you can let the rule do unsupervised.
How do I create an automated workflow?
Write the four parts down before you open any settings screen. Then check whether the tool you already pay for can express the condition, because that's where most attempts die: triggers and actions are nearly always available, and the condition is the part that needs a test your filter can't make. You almost certainly won't need code for any of this, but be clear that no-code is a promise about building it, not about maintaining it: you'll still be the person working out why last Tuesday's run produced two tasks instead of one.
What should not be automated?
Data, rules and repetition automate well. Judgement, relationships and anything with feelings in it don't. Three tests worth applying before you build: how variable is it, because a job full of exceptions needs a condition you can't actually write down; how often does it run, since anything quarterly or rarer usually costs more to set up than it saves; and how bad is a wrong answer, because irreversible actions want a human in the loop rather than an alert afterwards.
Can AI replace rule-based automation?
Mostly not, and the two are better at different halves of the same rule. Rules are more reliable for the deterministic parts, the if-then logic and the actions. Models are better at the judgement-shaped part, which on this page is almost always the condition: deciding what a message is about, or whether this case is one the rule should touch. Using a model for the condition and a rule for everything else is the combination that tends to hold up.