> ## Documentation Index
> Fetch the complete documentation index at: https://docs.dmly.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Common mistakes
> Why a bot never replies, why publish is blocked, and the WhatsApp and AI traps that catch most flows.
Most automation support tickets come from a short list of causes. This page covers what actually
goes wrong, in the order it wastes the most time — starting with the bot that looks correct and
never replies.
Three things do not work where people assume they do:
* **WhatsApp text messages cannot carry buttons.** Buttons and quick replies on a plain message
step are a Meta feature, not a WhatsApp one. Use the Buttons Message step instead.
* **Ice breakers and the persistent menu exist for Facebook, Instagram and Telegram only.** There
is no equivalent on WhatsApp or the LiveChat widget. See [Ice breakers](/automation/icebreakers).
* **An AI Reply step needs a connected AI provider.** With none connected the step is skipped at
runtime — it does not fail loudly. See [AI replies](/automation/ai-replies).
## The bot never replies
The flow is published, the trigger looks right, and nothing happens. There are four reasons a flow
refuses to start for a contact, and two of them leave no trace in the Inbox.
Pausing the bot on a conversation freezes every automation for that contact. The one exception:
a flow that contains a Resume bot step still runs, because otherwise the step that lifts the
pause could never be reached. Check the conversation in the [Inbox](/inbox/overview) before
anything else.
Only one activation of the same automation can be live for the same contact at a time. If a
step is still waiting for that contact's reply, a new trigger is dropped. This is written to
[Logs](/troubleshooting/logs) as a warning with the reason `already_active`.
If the trigger has this set, the flow starts once for that contact and never again — including
for runs that failed or were cancelled. Logged with the reason `once_per_contact`.
Editing the canvas changes the draft. Until you publish, the live bot is still the previous
version — or nothing at all. This one is silent: no log entry, no error.
When a bot "just doesn't fire", open [Logs](/troubleshooting/logs) and filter to automation
warnings. `already_active` and `once_per_contact` name themselves. If nothing is logged at all,
the cause is a paused bot or an unpublished draft.
Abandoned runs are cleared automatically — a run whose worker died mid-step is reaped rather than
blocking that contact forever. If a contact seems stuck, wait rather than rebuilding the flow. More
in [Automation not triggering](/troubleshooting/automation-not-triggering).
## The customer gets two replies
Duplicate messages are not just untidy. On WhatsApp, contacts who receive the same message twice
block and report at a higher rate, and that feeds your number's quality rating. See
[WhatsApp rules and limits](/channels/whatsapp-limits).
**Two bots on one channel.** Publish is blocked when another active automation on the same channel
answers the same trigger. If both reply to everything, you get: *"…is already active on this channel
and replies to every message, so both would respond. Give one a specific keyword, or pause the
other before publishing."* If they merely share a keyword, the message names the keyword and the
other automation. Fix it by giving one a specific keyword, or by pausing the other — not by
publishing again.
**A workspace notification already covers the event.** Automations and workspace notifications are
separate systems and neither knows what the other sent. Build a flow on `appointment_booked`,
`appointment_rescheduled`, `appointment_cancelled`, `invoice_sent`, `payment_succeeded`,
`payment_failed` or `subscription_payment_failed` while the matching notification is switched on,
and the client gets both. The builder warns you on the trigger step: *"A workspace notification
already fires on this event — clients may receive a duplicate. Review Notification settings."* This
is a warning, not a block — publish succeeds and the duplicates go out. Turn one of the two off.
## Publish is blocked
The builder shows an amber badge on any step that needs work, and a **Needs attention** list inside
the step. Some of those are advice; the ones below stop publish.
### Every branch needs its own path
A branching step routes to a named output, and an output with nothing attached is a dead end. Three
things block publish over an unconnected output, and both sides are required — not just the one you
expect to happen:
* **Condition** — both TRUE and FALSE
* **Find Order** — both FOUND and NOT FOUND
* **Reply buttons and quick replies on a message step** — each one, individually
**Randomizer** is checked on its shape rather than its wiring: publish requires 2 to 5 branches with
weights totalling exactly 100%, but it does not check that each branch leads anywhere.
The FALSE branch is the one people skip. A condition with only TRUE wired up will not publish, and
a contact who fails the test has nowhere to go.
**Buttons Message**, **List Message**, **Check Stock** and **CSAT Survey** flag their unconnected
outputs on the step, but that is advice — it does not block publish. A Buttons Message with a dead
button and a List Message with dead rows both publish. On **CSAT Survey** the builder only asks you
to connect at least one score; unconnected scores never stop publish. What publish does enforce on
the first two is Meta's size limits: 1–3 buttons with titles of 20 characters or less, and 1–10
rows. Advisory or not, a dead output is still a dead end for the contact who picks it.
### One output connects to one step
Each output handle allows exactly one outgoing connection. To send a contact down several paths you
use several named outputs — not several lines out of the same one. Dragging a second line from an
output that already has one produces *"Step … has 2 connections from one output (out) — each output
can connect to only one next step. Remove the extra connection(s)."* The same rule rejects an
imported flow file, so a flow that was hand-edited outside DMLY will refuse to load.
### No orphan steps
Every step except the trigger needs an incoming connection. A step you dragged onto the canvas and
never wired up blocks publish with *"Node … is not connected to the flow."* Notes are exempt from
this check — they are annotations and are never validated.
Do not wire a note into the middle of a flow. A note reached by an edge ends the flow path, so
every step after it is silently skipped. Leave notes unconnected.
### The picks you left blank
A flow installed from a [template](/automation/templates) ships with deliberate placeholders. Publish
refuses until you fill them: a Send Template step with no template, a Send Store Product step with
no product, a Start Another Flow step with no flow selected, and a CTA URL step with no link.
**Send Store Product** and **Send Product** are two different steps. Only Send Store Product is
checked at publish. A blank Send Product shows an amber badge and publishes anyway.
## WhatsApp traps
**Buttons on a text message.** Covered above — the Buttons Message step is the WhatsApp one.
**Starting a store-triggered flow with a normal message.** A contact who abandoned a cart yesterday
is outside WhatsApp's 24-hour window, so an ordinary send silently cannot reach them. The builder
flags it: *"Store-triggered contacts are usually outside the 24h window — start with a WhatsApp
Template (or a Checkout Link with a template fallback)."* Make the first step after a `store_`
trigger a Send Template step, or a Checkout Link with a template selected as its fallback. See
[Message templates](/broadcasts/message-templates).
**Product events with no recipient.** `store_product_back_in_stock` and `store_inventory_low` are not
about one person, so there is nobody to message until you set the **notify contacts tagged** tag on
the trigger.
**Meta's size limits, which are hard limits.** A Buttons Message needs 1–3 buttons with titles of 20
characters or less. A List Message needs 1–10 rows across at most 10 sections; row titles cap at 24
characters and descriptions at 72. Body text caps at 1024, headers at 60, footers at 60. Exceeding
them is not a style problem — WhatsApp rejects the send.
**Empty template variables.** A Send Template step with a blank variable is flagged — `Variable {{1}} is empty.` — for each one. Fill every one.
## Facebook and Instagram traps
* **Instagram does not support call or webview buttons.** They exist in the picker on Messenger.
Instagram gets quick replies and Open URL only.
* **More than 3 buttons or 13 quick replies** breaches Meta's limits and is flagged on the step.
* **A URL button with no valid link** fails at send time, not at build time — the builder catches it
first if you let it.
## AI steps
The AI Reply step is built so a flow never stalls on it. That is usually what you want, and it is
also why a broken AI step is easy to miss — everything looks fine, the contact just gets nothing
useful.
* **No provider connected** — the step is skipped and a system note appears in the conversation:
*"✨ AI step skipped — no AI provider is connected."* The flow continues.
* **Your plan does not include the AI Agent** — same shape: *"✨ AI step skipped — your plan does
not include the AI Agent."* Publish is also blocked up front with *"This automation uses an AI
step, which your plan does not include."* See [Plans](/billing/plans).
* **An error or an empty reply** — the step's **Fallback message (on error / empty reply)** is sent
instead. Write a real one. The default is *"Sorry, I couldn't process that just now — a team
member will follow up shortly."*
* **Too many AI calls in one conversation** — an AI step with more flow after it is capped at
three calls per run, then skipped: *"✨ AI step skipped — per-conversation AI limit reached."*
If you hit that, the flow is looping back to the step. An AI step at the end of a path — its
**out** output leading to an End step, a note, or nothing, which is how a customer-service bot
is normally built — is treated as a conversation instead and capped at 40 replies. Reaching that
cap moves the flow past the step quietly, with no system note.
**Document search is on by default and does nothing.** A new AI Reply step has **Document search
(File Search)** enabled, but the tool is dropped entirely unless you select at least one vector
store. Create a store on the provider's Integration page first — the step tells you so: *"No vector
stores yet — create one on the provider's Integration page (Vector stores tab)."* See the
[knowledge base](/integrations/knowledge-base).
**Reasoning effort only applies to OpenAI.** The card is hidden for Claude, Gemini and DeepSeek
because none of them support it — including DeepSeek's `deepseek-reasoner` model. Setting it
elsewhere has no effect.
**Document search is not available on every provider.** Claude and DeepSeek have no file search, so
the step says so and there is no Vector stores tab on their Integration page.
**An empty prompt is flagged but not fatal.** The step warns *"AI prompt is empty."* At runtime it
falls back to the built-in Customer Service prompt, so an AI step never runs promptless — but it
also will not do what you meant. `{{business_name}}` in a prompt resolves to your workspace name.
Use the **Playground** tab on the AI Reply step before you publish. It runs your prompt and shows
the reply plus a **Tool calls** trace, with no real message sent and no contact touched.
## Before you publish
How steps, outputs and the canvas work.
Draft versus published, and what activation changes.
Work through a bot that will not start.
Where suppressed runs and delivery failures are recorded.