Automation and bots
Letting Lynomia Chat do the repetitive work.
Automation rules
An automation rule is three things, in this order: one event, the conditions that must be true, and the actions to run. Nothing else. If you can say "when X happens, and Y is true, do Z", you can build it. Rules run on the server, so they work overnight, at the weekend, and while every agent is logged out. When to use one When the trigger is a fact rather than a judgement, and you want the same thing to happen every time. Routing new conversations to a team. Labelling anything that mentions a word you care about. Raising the priority of a customer you have already described as an audience. When not to use one - When somebody has to read the conversation first. That is a macro. - When you need to ask the customer something and branch on the answer. A rule runs its actions and finishes; it cannot wait. That is the flow builder — see Automation or flow builder?. What you need first An administrator account. Rules live under Settings → Automation. Commerce triggers also need a store connected under Commerce. The real trigger events A rule picks exactly one. There are twelve. | Group | Events | |---|---| | Conversations | conversation created, conversation updated, conversation opened, conversation resolved, message created | | Commerce | order created, order updated, order paid, order shipped, order delivered, order cancelled, order refunded | A Commerce trigger fires when Lynomia Chat reads a change in a linked customer's orders, and acts on the contact's most recent conversation. If that contact has no conversation, nothing runs. Which Commerce events ever fire depends on the platform: WooCommerce has no shipped or delivered status, and Shopify has no cancelled one. The recipe gallery says so next to each affected recipe. What conditions and actions are available Conditions cover the conversation (status, priority, inbox, assignee, team, labels), the message (its text, its type, whether it is a private note), the contact (email, phone, company, country, language), your custom attributes, whether the contact is in a shared audience, and what Commerce knows about them. On a Commerce trigger you can also test the order's store and store platform. Conditions join with and or or, and the form expects at least one. Actions cover ownership (assign or unassign an agent or team), classification (add or remove a label, change priority), status (resolve, reopen, mark pending, snooze, mute), messages (send a message, add a private note, send an attachment, email a transcript, email a team) and send a webhook event. A Commerce trigger deliberately offers neither send a message nor send an attachment: a store event is not a customer message, and the conversation may be outside the WhatsApp 24-hour window. Use a private note and a team instead. Recipes A recipe fills in a working rule and asks only for what it cannot know — which team, label, store, audience or amount. The eleven cover order routing, refund escalation, paid-order priority, cancelled-order follow-up, audience labelling and priority, spend-based routing, open-order routing, sending an order event to another system, and greeting every new conversation. The same gallery also offers a setup recipe that creates a shared audience and a rule that uses it, in one go. A rule created from a recipe starts switched off. You read it, edit the wording, and turn it on yourself. A rule you build by hand is live the moment you save it. Either way it is then an ordinary rule. A worked example Refund questions must reach the returns team within seconds, at any hour. 1. Settings → Automation → Create automation. Name it Refund to returns. 2. Event: message created. 3. Condition: content — contains — refund. 4. Actions: add label refund, assign team returns, priority high. 5. Save, send yourself a WhatsApp message containing the word, and check the conversation. Who can do this Administrators only — creating, editing, cloning, switching on and deleting. Automation is not one of the permissions a custom role can be granted, so a custom role cannot be given this page. See roles and permissions. Limits - No time-based conditions of any kind: no business hours, time of day or day of week. - No priority escalation. A rule sets a priority once. Nothing raises it as a conversation ages. - A rule's own actions do not trigger other rules. This prevents loops, and means rules cannot be chained. - One event per rule. Two events means two rules, and both can match the same change. - "Add label" labels the conversation, never the contact, and there is no trigger for a contact changing. See Labels or shared audiences?. - A failed action is not reported. Each action is attempted in turn; the rest still run, silently. - Commerce rules never wait, and each runs at most once per order change. - Waiting rules are optional and off by default. A rule can act only if something is still true after 10 minutes to 30 days, but it must be enabled for your account, and on a conversation event it can test only status and inbox. Editing such a rule discards the waits already armed. Related - Automation or flow builder? - Macros or automation? - Flow builder - Shared audiences If it does not work Nothing happened. Check the switch first — a rule from a recipe is off until you turn it on. Then check that the conditions can be true at the moment the event fires. A condition on a label the rule itself adds later never matches. It ran twice. Two rules on two events can both match one change. A Commerce rule never fires. Either your platform does not report that status, or the contact has no conversation to act on.
Flow builder
A flow is a conversation drawn as a diagram. Each box is one step — send this, ask that, check something, hand over to a person — and the lines between them are the paths the conversation can take. The thing that separates a flow from an automation rule is memory. A flow waits. It asks the customer a question, stops, and when the reply arrives it picks up where it left off, knowing everything the customer has already said. When to use one When the next step depends on an answer you do not have yet. A menu of departments. An order-number lookup. A complaint taken over WhatsApp. Anything where "it depends what they say" is the honest answer. When NOT to use one - On any channel other than WhatsApp Cloud. This is a hard limit, not a default. See below. - When nothing needs to be asked. Labelling, routing and priority on a fact you already have is an automation rule, which is simpler and easier to read. - To start a conversation. A flow cannot begin one. It only ever answers one. - For a store event, a schedule, a webhook or a campaign. None of these can enter a flow. WhatsApp Cloud only A flow runs on WhatsApp Cloud inboxes, and nothing else. Attach a flow to any other channel and publishing is refused with "Not supported on ". If a conversation on an unsupported channel somehow reaches a flow, it goes straight to your team instead. How a flow is entered One way only: a customer's message on a conversation the flow owns. For that to happen, the flow must be the inbox's active bot, the conversation must be pending, and nobody may be assigned to it. The message is then matched against the Start node's keywords and conditions, if you set any. If it matches, a session begins. If not, the conversation goes to your team at once. What you need first An administrator account, the flow builder enabled for your account, and a connected WhatsApp Cloud inbox (Connect WhatsApp). Order lookups also need Commerce. The nodes | Group | Nodes | |---|---| | Messages | Send message, Send WhatsApp template | | Ask and wait | Question, Buttons, List, Delay | | Logic | Condition, Audience, Commerce condition, Go to | | Customer | Set contact attribute, Set conversation attribute, Add label, Remove label | | Commerce | Order lookup | | Team | Assign agent, Assign team, Human handoff | | Integration | Webhook | | Flow | Start, End | Four of these wait for the customer: Question, Buttons, List and Delay. Everything else runs straight through. A Question stores the answer — in the run, on the contact or on the conversation — for use later in message text, and re-asks when the answer does not fit. An Order lookup finds the newest order of the contact's own matched store customer, or the order number they quote; it never reads another customer's order, and never changes one. Steps 1. Settings → Flow Builder → New flow, or Start from a template. 2. Build the canvas. Save draft as you go; nothing you save affects a customer. 3. Press Test to run the saved draft against a test contact. Nothing is sent or stored. 4. Press Publish. Problems are listed next to the nodes that caused them. 5. Attach the published flow to a WhatsApp Cloud inbox, as you would any bot. Templates Eight ready-made flows: order tracking, order-issue intake, department routing, a FAQ menu, complaint intake, VIP priority routing, an Arabic-or-English welcome, and a welcome that collects the request. Each asks for your teams, labels and language, then creates a draft whose every message and branch is yours to edit. What publishing refuses Publishing is the gate, and it checks the whole graph: - exactly one Start, with nothing leading into it - every required output connected — including every button and every list option - every node reachable from Start - no loop that never waits for the customer - a Go to that points at a real node, not at itself or Start - teams, agents, labels, attributes, audiences and stores that exist in this account, and known variables - every attached inbox able to run every node in the flow An optional output — a question's invalid or timeout, a menu's other, a lookup's not found — may be left unconnected on purpose. If the conversation takes it, your team gets the conversation. Who can do this Administrators only. Flows are not one of the permissions a custom role can be granted. See roles and permissions. Limits - WhatsApp Cloud only. No other channel, and no plan to accept one here. - Entered from a customer message only. Not from an order change, a schedule, a webhook or a campaign. - WhatsApp's own shape applies. At most 3 reply buttons, titles of 20 characters; one list of at most 10 rows; 4,096 characters of text. - At most 300 nodes and 900 connections per flow. - A handoff ends the flow. Once a person takes the conversation it stops and does not resume. An agent's reply ends the session too, including one sent from the WhatsApp Business app on a coexistence number. - One published version at a time. Conversations already running stay on the version they started on. - Disable before deleting. Disabling stops new sessions and hands the live ones to your team. - Order lookups are capped at ten per conversation per hour. - Outside the WhatsApp 24-hour window a flow cannot send ordinary text, so it hands over. An approved template still sends. Related - Automation or flow builder? - Automation rules - Agent bots - Connect WhatsApp If it does not work Publish is refused. Read the list above the canvas. Each problem names its node. The flow never starts. Check it is published, attached to a WhatsApp Cloud inbox, and that the conversation arrives pending with nobody assigned. Then check the Start keywords — one the customer did not type sends the conversation to your team. It stopped halfway. Open Sessions on the flow. Each session shows where it ended and why.
Automation or flow builder?
Both do things to a conversation without a person involved. Both can label it, route it, change its priority and call a webhook. The lists overlap enough that reading them will not tell you which to use. One sentence will: An automation rule reacts and finishes. A flow remembers and waits. A rule is a reflex. Something happens, the conditions are checked once, the actions run, it is over. A flow is a conversation: it sends something, stops, and the customer's reply decides what happens next. Side by side | | Automation rule | Flow | |---|---|---| | What starts it | one of twelve events | a customer's message, nothing else | | Channels | every channel | WhatsApp Cloud only | | Can wait for a reply | no | yes, that is the point | | Remembers what was said | no | yes, for the whole session | | Branches | no — conditions decide whether it runs at all | yes, on every answer | | Can ask a question | no | yes | | Can send a menu or buttons | no | yes | | Can start from a store event | yes, seven order events | no | | Runs with nobody online | yes | yes | | Needs the conversation pending and unassigned | no | yes | | Review before it goes live | an on/off switch | a draft you publish | | Who can build it | administrators | administrators | The question that decides it Do you already know everything you need? If yes — the message mentioned "refund", the contact is in the VIP audience, an order was just refunded — then you have all the facts at the moment the event fires. Use a rule. If no — you need to know which department, which order number, what went wrong — then you have to ask, and asking means waiting. Use a flow. What only a rule can do - Start from something other than a message. Seven order events, a conversation being resolved, a conversation being opened. A flow cannot be entered by any of these. - Work on channels other than WhatsApp Cloud. A flow cannot. - Act on a conversation that is already being handled. A flow only ever runs while a conversation is pending with nobody assigned; a rule does not care. - Email a team, or email a transcript. There is no flow node for either. What only a flow can do - Ask, and use the answer. The reply can be stored on the contact or the conversation and quoted back in later messages. - Branch. Buttons and lists create one path per option. A condition node splits the path in two. - Look up an order. The contact's own newest order, or a number they type. - Hand over deliberately, with a team, a priority, labels and a note attached to the handoff. - Be tested before anybody sees it. A flow draft runs against a test contact with nothing sent. Neither of them can - Behave differently out of hours. There is no business-hours, working-hours or time-of-day condition anywhere, and no flow node for it. Whatever you build runs the same at 2pm and at 2am. - Escalate a priority over time. Both set a priority once. Nothing raises it as a conversation ages. - Label a contact. Both label the conversation. See Labels or shared audiences?. - Start a conversation. For that you need a WhatsApp campaign. Use both, in order The usual shape of a working setup is a flow in front and rules behind it. 1. The flow greets the customer on WhatsApp, asks what they need, and hands the conversation to the right team with the answer already written down. 2. A rule on conversation created labels anything from a high-spend audience, so the right conversations are findable and reportable whatever path they took. 3. Another rule on order refunded raises the priority of that customer's latest conversation and routes it to returns — a store event the flow could never have seen. Each does the part the other cannot. Neither is a fallback for the other. A worked example of choosing wrongly You want: "if nobody has replied within four hours, tell the manager." Neither tool does this well, and knowing that early saves a day. A flow cannot: it is not running once a person has the conversation. A plain rule cannot: it reacts to an event, and "four hours passed" is not an event. There is an optional waiting rule that handles exactly this shape — no teammate has replied for N — but it has to be enabled for your account and is off by default, and it can only test the conversation's status and inbox. The honest answer is to check whether waiting rules are enabled for your account before designing around them. Related - Automation rules - Flow builder - Macros or automation? - Agent bots If it does not work I built a flow and it never ran. It was probably not a WhatsApp Cloud inbox, or the conversation was not pending and unassigned. Both are hard requirements. I built a rule to ask the customer something. A rule's "send a message" sends and finishes — the reply goes to your team, not back to the rule. Rebuild it as a flow. I need an order change to start a conversation flow. That combination does not exist. A store event can only start a rule, and a rule cannot send a message to a customer on a Commerce trigger.
Agent bots
An agent bot is a service you write and host. Lynomia Chat posts conversation events to a URL you give it, and your service decides what to do and replies through the API using the bot's own credentials. There is no canvas and no rule list — just events in, API calls out. It can do anything your code can do, and nothing it cannot. When to use one - Your logic lives somewhere else already. An order system, a CRM, a booking engine, a model you host. - You need to call something during the conversation that the product has no node for. - You want a bot on a channel a flow cannot run on. A flow is WhatsApp Cloud only; a bot receives events from whatever inbox you attach it to. When NOT to use one - When a flow would do. A menu, a question, an order lookup and a handoff need no code, no server and no uptime from you. See Agent bot or flow? below. - When nothing has to be asked. Routing and labelling on facts you already have is an automation rule. - When you cannot keep a service up. If your endpoint is down, conversations go unanswered. What you need first An administrator account, and an HTTPS endpoint that accepts a POST and answers quickly. Steps 1. Settings → Bots → Add Bot. 2. Give it a name, a description and the webhook URL. An avatar is optional. 3. Save. You are shown an access token and a webhook secret. Copy both now; they stay available in the bot's settings, and either can be regenerated later. 4. Open the inbox you want the bot to answer, and select it under the inbox's bot setting. One bot per inbox. 5. Verify the signature on the first delivery, then start replying through the API with the access token. The events your webhook receives | Event | Sent when | |---|---| | message created | a message is added to a conversation the bot can see | | message updated | an existing message changes | | conversation opened | a conversation moves into open | | conversation resolved | a conversation moves into resolved | | conversation status changed | its status changes, with what changed | | conversation updated | something else about it changes, with what changed | A website inbox also sends an event when a visitor triggers the widget. There is no "conversation created" event for bots. The first thing your service hears about a new conversation is its first message. How a delivery is signed Each POST carries a JSON body, a unique delivery identifier, a timestamp, and a signature: HMAC-SHA256 over the timestamp and the raw body, keyed with the bot's webhook secret. Recompute it over the raw bytes you received, compare, and reject anything that does not match or carries an old timestamp. The delivery identifier is how you make your handler idempotent, which matters because deliveries can repeat. A worked example You want order status answered from your own warehouse system on a WhatsApp number. 1. Create the bot with your endpoint's URL and copy the secret and token. 2. Attach it to the WhatsApp inbox. New conversations arrive pending, and your endpoint gets each message. 3. Your service verifies the signature, looks the order up, and posts a reply through the API as the bot. 4. When it cannot answer, it assigns a team, and your people pick the conversation up as usual. Agent bot or flow? | | Agent bot | Flow | |---|---|---| | Who runs the logic | your server | Lynomia Chat | | Who keeps it up | you | nobody, it is hosted | | Channels | any inbox you attach it to | WhatsApp Cloud only | | Built by | a developer, in code | an administrator, on a canvas | | Reaching your own systems | anything | a webhook node, and order lookups | | Buttons and lists | you construct them | nodes for both, with WhatsApp's limits enforced | | Changing it | deploy | edit the draft and publish | | Testing it first | your own staging | built in, against a test contact | Pick a flow unless you need to reach a system of your own, or a channel a flow cannot run on. A flow is less work and has nothing to break on your side. Flows do not appear on the Bots page. They are both bots underneath, but the page deliberately lists only webhook bots, so each is managed in one place. Who can do this | | Agent | Administrator | |---|---|---| | See the bots list | yes | yes | | Create, edit, delete | no | yes | | Regenerate the token or secret | no | yes | Bots are not one of the permissions a custom role can be granted. See roles and permissions. Limits - One active bot per inbox. A flow and a webhook bot cannot both answer the same inbox. - A bot's type is fixed at creation. A webhook bot cannot become a flow, or the reverse. - Deliveries time out quickly — five seconds by default. Acknowledge fast and do the work afterwards. - Retries are limited. A delivery your service answers with 429 or 500 is retried up to three times, a few seconds apart. Any other failure is not retried. - A failing bot releases the conversation. If a message delivery keeps failing, the conversation moves from pending to open and a note is added, so a person picks it up — unless your account is configured to keep it pending. - Nothing is queued while your endpoint is down, and there is no delivery log to read here. Log on your side. - The bot's messages obey the channel's rules, including the WhatsApp 24-hour window. Related - Flow builder - Automation or flow builder? - Automation rules If it does not work No events arrive. Check the bot is selected on the inbox, and that the URL is reachable from outside your network over HTTPS. Signatures never match. Sign the raw body exactly as received, before any parsing or re-serialising, and include the timestamp in the signed string. Conversations keep jumping to open on their own. That is the failure path above: your endpoint is erroring. I cannot see my flow on the Bots page. Flows are listed in the flow builder.