Stopping a flow, and avoiding double messages
Every automation runs on the same incoming message. That is a feature until two of them answer at once.
Double messages happen because more than one automation matched the same incoming message, and nothing told the second one to stay quiet. It is the single most common complaint about a WhatsApp setup that has grown past three or four rules.
The behaviour is deliberate. Every published automation gets a look at each message, which is what lets a tagging rule and an answering rule both do their job on the same message. The cost is that two rules which both send something will both send something.
The four ways to stop
| Block | What it stops |
|---|---|
| End Automation | This run, here. Nothing after it in this path executes. |
| Pause Before Repeating | This flow running again for this customer within the window you set. |
| Cancel Pending Question | The bot waiting for an answer to a question it asked earlier. Sends nothing. |
| Conditions and guards | The run before it ever reaches a send step. |
They are not interchangeable, and reaching for the wrong one is why the problem often survives the first attempt to fix it.
Case one: two rules answering the same message
Classic setup — a broad welcome flow triggered by any first message, and a keyword flow for "price". A new customer's opening message is "how much is the blue one", and both fire.
Three fixes, in order of how well they hold up:
- Make the broad rule narrower. Add an "is this the first message" condition to the welcome flow so it only greets genuinely new conversations.
- Use rule priority. Automations run in priority order, so the specific rule can handle the message before the general one.
- Put an End Automation on the paths that should be silent so a matched run terminates instead of falling through to a send step.
The first is almost always the real fix. A rule that triggers on everything is a rule you will keep debugging.
Case two: the bot talking over your team
Different problem, same symptom. Your flow asked a question and is waiting. A colleague sees the chat and replies by hand. The customer types — and their message is captured as the answer to the bot's question rather than reaching your colleague.
The fix is a tiny separate automation that sends nothing at all:
Two blocks, one problem solved
Every account with both automation and a human team should have this, and most do not. The longer version, including what to do about the conversation status, is in handing a chat from bot to human.
Case three: the same flow firing repeatedly
A customer sends three messages in quick succession because that is how people type. A keyword flow with no repeat protection replies three times.
Pause Before Repeating is the block for this, and a few minutes is usually enough. It is worth adding to every keyword-triggered flow as a matter of habit, not because you expect the problem but because it costs nothing when it is not needed.
Case four: an order flow that runs twice
Store events can arrive more than once — a webhook retried, or two events that both describe the same shipment. A flow that sends a tracking message on each one sends the customer two identical messages.
Guard against it the same way: repeat protection on the flow, and where the information matters, a condition that checks whether you have already recorded sending it. Saving a marker to a contact field and checking it before sending is crude but completely reliable.
End Automation is a step, not a setting
Worth spelling out because it trips people up: End Automation ends the path it is on. If your flow branches and only one branch ends, the other branch carries on happily.
So the useful mental model is that every branch needs an ending, and "falls off the end of the flow" is a fine ending for most of them. The explicit block is for when you want to stop early — usually because a condition told you this customer should not receive what comes next.
An audit worth doing once
- List every published automation and what triggers it.
- Mark the ones that trigger on any customer message. Those are the overlap risk.
- For each, ask what stops it when a more specific rule has already handled the message.
- Send yourself three messages that should each match a different rule, and read what actually comes back.
- Check that the agent-message rule exists.
Half an hour, and it catches most duplicate-message problems before a customer does. How many rules you should be running in the first place is covered in how many automations should a store run.
Why duplicates cost more than embarrassment
Two consequences, and the second is the expensive one.
Duplicate free-form replies inside the 24-hour window do not cost money — service conversations have been free and unlimited since 1 November 2024 under Meta's pricing documentation. Duplicate templates outside the window are billed twice.
More seriously, customers block businesses that message them twice for no reason, and blocks feed your quality rating. A falling rating can drop your messaging tier, and the ladder runs 250 → 2,000 → 10,000 → 100,000 → unlimited under Meta's messaging limits documentation, so a sloppy flow can end up costing you reach you spent months earning.
Frequently asked
Can I make one automation block all the others?
Not with a single switch. Priority ordering plus conditions on the broad rules is the mechanism, and it is more predictable than a global override would be.
Does turning an automation off stop runs already in progress?
It stops new runs. Treat anything already waiting inside a delay as in flight, and prefer a short test delay while you are still changing a flow.
Why does a tagging rule not cause duplicates?
Because it sends nothing. Rules that only tag, note or assign can overlap freely — it is send steps that need policing.
Two automations both send, but I want that.
Then space them with a delay so they do not land together, and be sure the second still makes sense to someone who just read the first.
Designing so it never happens
Everything above is a fix. The cheaper approach is a small set of habits that stop duplicates arising:
- One job per automation, named after the job. If you cannot say what a rule does in six words, it is doing two things.
- Exactly one rule may greet. Everything else assumes the conversation is already open.
- Exactly one rule may answer an unmatched message. That is your fallback, and it should be the lowest priority thing you have.
- Rules that only tag, note or assign are free to overlap. They send nothing, so they cannot duplicate anything.
- Repeat protection on every keyword flow, as a default rather than a reaction.
Follow those and the overlap question mostly stops arising, because at any moment only one rule in the account is entitled to speak.
The debugging order when it does happen
| Step | What you learn |
|---|---|
| Read both messages the customer received | Which two rules sent them — the wording usually names them |
| Open each rule's activity view | Whether both really ran, or one ran twice |
| Check the triggers | Whether one is broader than you remembered |
| Check repeat protection | Whether a burst of messages caused it |
| Re-send the exact message yourself | Whether the fix worked |
The third row is the answer more often than anything else. Rules widen over time — someone adds a keyword, someone removes a condition — and a rule that was specific in January is general by June.
One case where two messages are correct
An order confirmation and a shipping notice for the same order are two messages and should be. So are a question and its follow-up. The test is not how many messages arrived but whether the second one makes sense to someone who has just read the first.
If it reads as a repeat, it is a duplicate no matter which rule sent it. If it reads as the next thing, it is a conversation. Timing and wording, covered in delays and follow-ups, are what separates the two.
What "priority" actually changes
Automations carry a priority, and it decides the order they are considered in rather than which one wins outright. That distinction matters: giving a rule the top priority does not silence the others. It only means it acts first.
So priority is useful for sequencing — tag before you answer, check a guard before you send — and it is not a substitute for conditions. If two rules should never both speak, the reliable mechanism is a condition on the broader one, and priority is what tidies up the order of everything else.
A workable convention for a store with a dozen rules:
| Priority band | What lives there |
|---|---|
| Highest | Opt-out handling, and anything that must run before a send |
| High | Tagging, notes, assignment — the rules that send nothing |
| Middle | Specific keyword and store-event flows |
| Low | The greeting |
| Lowest | The single fallback that answers everything else |
Written down once, it stops the ordering being re-argued every time somebody adds a rule — and it pairs with the naming discipline in how many automations should a store run.
A note on opt-out
One category of stop is not a design preference but an obligation. A customer who asks you to stop messaging must stop receiving messages, and that has to hold across every rule you run rather than the one they replied to.
Handle it at the highest priority, and handle it by recording the state on the contact rather than by ending a single flow — that way every other rule can check it before sending. The practical version is in opt-in rules for online stores.