Inactivity follow-up
Inactivity follow-up is an external node, like Global Keywords: it connects to nothing, you only configure it. It floats on the canvas and watches every wait in the flow. When the bot asked a question and the customer has gone quiet for a while, the node writes again — "Still there?" — and waits some more. If the customer answers, the conversation continues where it was. If the attempts run out, the conversation closes exactly as it would on the connector timeout.
It exists so you do not lose the customer in silence. Today the channel connector waits its full Timeout — 15 minutes by default — and closes without a word. With this node the flow insists first, in the tone and words you choose.
How It Works
The node acts at the same moment the connector timeout is armed: when the bot finished its turn and is waiting for the customer's answer on some node — a question, a set of options, a location request. A timer of its own is armed there with the Interval you configured.
If the interval elapses and the customer still has not written, the node sends the follow-up message and counts one attempt. What happens next depends on whether you connected its output:
- Unconnected (the usual case), the conversation stays on the node that asked. The customer's next reply is processed by that same node, as if the follow-up never happened, and the timer is armed again for the next attempt.
- Connected, the conversation moves to the target node and runs it. Use it to offer a different way out — an Interactive Options with "Continue" and "Talk to an agent", say — instead of repeating the same question.
When the customer writes, anything at all, the timer is cancelled. And when the conversation moves to another node, the attempt count goes back to zero: every question in the flow gets its own attempts.
When the attempts are exhausted and the customer is still silent, the node does exactly what the connector timeout would do: it sends the connector's Timeout message if there is one, returns the conversation to the default responder and leaves the same expired-conversation notice. The connector's own timer is cancelled so nothing closes twice.
The Interval Must Be Shorter Than the Connector Timeout
The node only makes sense if it acts before the connector does. So the engine compares the Interval with the connector's Timeout every time it is about to arm it: if the interval in seconds is smaller, it is armed; if the connector has no timeout, it is armed too. If the interval is equal or larger, the node is not armed, the connector timeout stays in charge and the conversation gets a warning notice, one per conversation, naming both values so you fix one of the two.
With the default Timeout of 900 seconds, an interval of 5 minutes with 2 attempts writes to the customer at 5 and at 10 minutes, and closes at 15. The editor does not know the connector, so this check only happens at runtime: look at the flow notices after publishing.
Configuration
| Option | Description |
|---|---|
| Interval (minutes) | How long to wait without an answer before each follow-up. Whole number, minimum 1 |
| Max attempts | How many times to write again before closing the conversation. Minimum 1, default 2 |
| Messages | One or more follow-up texts. The first attempt sends the first one, the second the second, and once they run out the last one repeats. They accept flow {{variables}} |
| Description | Optional note for whoever reads the flow; the customer never sees it |
On the canvas the node shows a summary with the interval and the attempts, and a single optional output.
What the Customer Sees
Each follow-up is a regular bot message, sent through the conversation's own channel, with variables resolved as in a Message node. If you write three messages and configure five attempts, the third one repeats on attempts four and five. If you write only one, that one repeats every time.
A variable that nothing has set is not replaced: the customer sees {{variable_name}} as written. The publish check warns ahead of time about variables that no node in the flow assigns, and this node's messages count as variable usage.
Output Handles
| Handle | When it fires |
|---|---|
| Single output, optional | After a follow-up is sent. Unconnected, the conversation stays on the node that was waiting |
There is no error output and no input. The node never interrupts the flow: it only writes while nobody else is.
Publish Gate
| Rule | Result |
|---|---|
| Interval below 1 | Blocks publishing |
| Max attempts below 1 | Blocks publishing |
| No messages, or all of them empty | Blocks publishing |
| More than one Inactivity follow-up node in the flow | Blocks publishing: a flow carries only one |
| No incoming connection | Allowed, same as Global Keywords |
| Output not connected | Allowed: the conversation stays on the node that asked |
Prerequisites
The flow must run on a connector with a default responder, because that is where the conversation lands when the attempts run out; without one, the conversation is left with no flow, as with the connector timeout. And the Interval must be shorter than the connector's Timeout, in seconds — otherwise the node never acts.
Available on WhatsApp and web. Email flows do not offer it.
Things to Know
One node per flow. It applies to every wait in the flow, not to one particular question. If you want different follow-ups depending on the step, connect the output to a Conditional or to a set of options and decide there.
It is not armed while a human agent has the conversation. Like the connector timeout, it counts the customer's silence towards the bot, not towards an agent.
With the output connected, the conversation leaves. The target node processes it and the attempt count resets, so the "loop" of attempts only happens when the output is free. If the target asks something again, the follow-up is armed anew for that question.
The interval warning appears once per conversation. If you raise the connector Timeout or lower the Interval, new conversations pick it up at once; the ones that already got the notice do not repeat it.