Flow triggers explained: keyword, group, API and inbound call

Updated 2026-09-19 · 5 min read · By the Convo360 team

What a flow trigger actually is

A flow trigger is simply the answer to the question "when should this automation start?" Every visual flow you build needs one, chosen during flow creation, and it decides which real-world event hands control to that flow. Without a trigger, even a perfectly built flow never runs. It just sits there.

Think of it like a doorbell versus a motion sensor versus a key card versus a phone extension. Each device reacts to a different kind of event, and picking the wrong one means your automation either never fires, or fires for the wrong people at the wrong time.

Getting the trigger right matters more than it looks, because it is the one setting you cannot easily test in isolation, since you generally see it working (or not) only once real customers start interacting.

The trigger types, one by one

Convo360 groups every flow trigger into one of six kinds, and step 3 of building a flow asks you to pick exactly one before you can move on. Getting familiar with all six upfront saves you from building an otherwise-perfect flow around the wrong starting condition.

• When a new chat or call starts: the default entry point. Fires the first time someone messages or calls a number that has no other flow already running for them.
• When the user sends a keyword: fires only when an incoming message matches one of your chosen keywords, such as price, book or cancel. Useful for letting one number serve several separate automations.
• When a contact is added to a group: fires the moment a contact joins one or more chosen groups, whether that happens from the Contacts page, another flow's Add to Group step, or the API. This is the trigger behind most onboarding and drip sequences.
• When a call comes in: the voice equivalent of a new chat, used for inbound phone numbers.
• Only when another flow calls it: a sub-flow trigger. It never starts by itself; another flow has to reach it through a Call Sub-flow step.
• Manually / via API / inbound webhook / payment event: started from your own code, a third-party system posting to an inbound webhook, or a captured Razorpay payment.

A quick comparison

Precedence: what happens when more than one could match

A single incoming message is only ever handled by one flow. If a message matches a published keyword trigger, that flow takes it; otherwise, the first message from a new contact falls to the default "new conversation" flow, and later messages continue whichever flow (or sub-flow) that contact is already inside. This is why it is worth keeping keyword lists specific: two flows both listening for the word "help" will conflict, and only one can win.

Group and API triggers sit slightly apart from this: they do not compete with a customer's own incoming message, since they are started by an event on your side (a contact joining a group, a call from your code) rather than by something the customer typed.

Worth remembering too: once a contact is already inside a flow, whether it started from a keyword, a group, or a plain new conversation, their next messages are read as replies to that flow rather than as fresh attempts to trigger a different one, until that flow finishes, hands off through a sub-flow, or the contact sends a recognised reset phrase like "menu".

Common mistakes

• Expecting a CSV import to fire a group trigger: bulk imports deliberately do not fire it, only adding a contact one at a time (from the Contacts page, a flow step, or the API) does.
• Overlapping keywords across flows: two flows both reacting to "info" means only one will ever actually run.
• Forgetting the 10-minute guard: a given contact can only run the same group-triggered flow once every 10 minutes, so rapid repeated group changes will not loop it.
• Building a sub-flow with the wrong trigger: a reusable piece must be set to "Only when another flow calls it", or it will also try to run on its own for anyone who messages directly.
• Publishing a trigger change without testing: switching a live flow's trigger, or editing its keyword list, affects every future conversation the moment it is published, so a quick Preview / Try-it pass first catches an obvious mistake before real customers do.

Most of these mistakes only surface once real traffic hits the flow, which is exactly why the trigger deserves a second look before publishing, not just the conversation steps that follow it.

Combining triggers with sub-flows on Convo360

In Convo360's Flow Builder, step 3 of "Create flow" asks "When should it start?" and lists exactly these options. A common pattern is to keep one main flow on "new conversation", handle branching with Buttons or a List Menu, and use a Call Sub-flow step to jump into reusable pieces, such as an order-status or payment-reminder sub-flow, built separately with the "Only when another flow calls it" trigger.

Group triggers pair naturally with the Wait / Delay block to build a drip sequence: add a contact to a "New Enquiry" group, and a welcome-message-then-nudge sequence runs automatically on its own timeline for each contact.

Because Convo360 uses one flow builder for both chat and voice, the same trigger concepts apply to a voice agent too: "When a call comes in" is simply the voice equivalent of "When a new chat or call starts", and a voice flow can call a shared sub-flow exactly like a chat flow does, keeping logic such as order lookups consistent regardless of which channel the customer used.

Example conversation

Frequently asked questions

Related reading

Available across India — see WhatsApp & AI calling automation by state and city.