> ## 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. # Publish a flow > Publish a flow to make it live, understand what the builder blocks and warns about, and turn automations on and off. Building a flow does not make it run. A flow only reaches customers once you **Publish** it — that takes the version you have been editing, checks it, and turns the automation on. Until then it is a draft that only you can see. Two things have to be true for a flow to reply to anyone: it has a **published** version, and the automation itself is **Active**. Publishing sets both the first time. After that they move independently — you can pause an automation without unpublishing it, and you can edit a published flow without changing what customers get. **Quick automations have no Publish.** Publishing only exists in the flow builder. A quick automation is live as soon as you turn its **On/off** switch on in the Automation list — there is no draft to review and no version history. The rest of this page is about flows. See [Flow builder](/automation/flow-builder). ## Draft and published A flow keeps versions. The builder always edits the **draft**. The published version is a separate, frozen copy — it is the one the runtime actually reads. | | What it is | | -------------- | ------------------------------------------------------------------------------------- | | **Save draft** | Stores your canvas work. Changes nothing for customers. | | **Publish** | Checks the draft, freezes it as the live version, and sets the automation **Active**. | The builder autosaves your draft in the background — the label next to the buttons reads **All changes saved**, **Saving…** or **Unsaved changes**. If it says **Autosave failed — use Save draft**, use **Save draft** before you leave the page. **Editing a published flow is safe.** The moment you publish, DMLY opens a fresh draft from the same steps, so the canvas stays editable. Your edits sit in that new draft while customers keep getting the published version, until you publish again. Conversations already in progress finish on the version they started on. Publishing a change does not move someone mid-conversation onto the new steps — they see it next time they start the flow. ## Publish it A **⚠** badge with a count in the toolbar means some steps need attention. Select it to jump to the first one; the step's panel lists them under **Needs attention**. The badge itself never blocks **Publish**, but many of the issues it lists are the same ones the server refuses to publish on — clear them, or expect the red bar. Select **Publish**. The draft is saved first, then checked. If anything fails, a red bar appears under the toolbar with the reason and nothing is published. The status badge beside the flow name changes to **Active**, and the **Stats** button appears in the toolbar — per-step counts only exist once a version is published. ## What blocks publishing Four checks run, in this order. Each one stops the publish and tells you why. `This automation uses an AI step, which your plan does not include. Upgrade your plan to use it, or remove the AI step.` The AI step and the Google review-request step are both gated this way. Remove the step or change plan — see [Plans](/billing/plans). Structure comes next. The flow needs exactly one trigger, at least one step after it, and every branch wired up: * `The flow needs a trigger node.` * `The flow can only have one trigger node.` * `Add at least one action after the trigger.` * A **Condition** must connect both its TRUE and FALSE outputs. * A **Randomizer** needs between two and five branches, and their weights must total 100%. * **Find Order** must connect both FOUND and NOT FOUND. Four steps are also checked for the pick you have to make, and only those four: * `A "Start Another Flow" step has no flow selected.` * `A "Send Product" step has no product selected.` * `A "Send Template" step has no template selected.` * `A "CTA URL" step has no link.` No other empty field stops a publish. An empty message, a step with no media, a blank AI prompt or a webhook with no endpoint all publish — only the amber badge ever mentions them. Two automations on the same channel with the same trigger both reply, so the customer gets two messages. Publishing refuses: * Two catch-alls — `“” 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.` * A shared keyword — `The keyword “” is already used by the active automation “” on this channel — a customer who sends it would get both replies. Remove it from one automation before publishing.` A different trigger event never collides — only the same event on the same channel. More on keywords and match modes: [Triggers](/automation/triggers). Your plan caps how many automations can be **Active** per channel. Publishing activates this one, so it counts. Pause an automation you no longer need, or change plan. The keyword check only compares against automations that are **Active** at the moment you publish. If you pause one flow so a second one can publish, turning the first back on with the **On/off** switch does not re-run the check — and both would then reply. Before you reactivate anything, filter the list by **Active** and confirm nothing else already answers the same trigger. ## The amber warnings The **⚠** badge never blocks **Publish** by itself, but it is not a separate world from the publish check either — the two overlap, and neither contains the other. Clearing the badge is not a promise the flow will publish, and a step with no badge can still fail a structural check. Two of the things it flags will also fail the publish check, so fix these first: * `Not connected — no incoming edge.` — a step nothing leads to, so it never runs. Publishing fails with `Node "" is not connected to the flow.` * `Output “” connects to steps — each output can connect to only one next step.` — publishing fails with `Step "" has connections from one output () — each output can connect to only one next step. Remove the extra connection(s).` The rest are badge-only — nothing else will tell you: * `WhatsApp text messages can't carry buttons — use the Buttons Message step.` * `Instagram does not support call/webview buttons.` * `A workspace notification already fires on this event — clients may receive a duplicate. Review Notification settings.` — on triggers like a booking confirmation or a payment receipt, where DMLY may already be messaging the contact. * `Store-triggered contacts are usually outside the 24h window — start with a WhatsApp Template (or a Checkout Link with a template fallback).` — see [WhatsApp rules and limits](/broadcasts/whatsapp-rules-and-limits). Notes on the canvas are never flagged. ## Turn automations on and off Every row in the Automation list has an **On/off** switch. It flips between **Active** and **Paused**, and it is the only control you need day to day. * **Pausing** never touches the published version. The flow stops starting new conversations; turn it back on and the same version runs again. Nothing is lost. * **Turning on** re-checks your plan's cap on active automations per channel. If you are at the limit, the switch springs back and the page tells you why. * A quick automation that has never run is **Draft** — the switch is how it goes **Active**. Pausing an automation is not the same as pausing the bot for one person. To stop the bot in a single conversation, pause it on that contact from the [Inbox](/inbox/overview). ## Managing the list The Automation list shows **Builder**, **Platform**, **Trigger**, **Status**, **Usage** and **Last run** for every automation on the selected channel, ten to a page. Four controls narrow it: **Search automations…** by name, plus **All builders**, **All triggers** and **All statuses**. There is no multi-select. Automations are turned on, off and deleted **one at a time** — the filters are for finding rows, not for acting on them in bulk. There is no "pause everything" control. Each row's **⋮** menu has **Open builder** (or **Edit** for a quick automation), **Analytics**, and **Delete** if your role allows it. Deleting an automation removes its versions with it and cannot be undone. The status filter offers **Failed**, but no automation is ever set to that status — the filter always comes back empty. A *run* can fail without the automation failing; that shows up in **Analytics**, not here. Check, in this order: the automation is **Active**, not **Paused** or **Draft**; the flow has a published version (the **Stats** button in the builder only appears when it does); and the trigger matches what customers actually send. Then read [Automation not triggering](/troubleshooting/automation-not-triggering) and [Logs](/troubleshooting/logs). You are almost certainly editing the draft of an already-published flow. **Save draft** and autosave both write to the draft only. Select **Publish** to make the edits live. Build the flow itself — steps, branching and the canvas. Choose what starts a flow, and set its keywords and match mode. Start from a ready-made flow instead of a blank canvas. What goes wrong most often, and how to avoid it.