Support Flows

Support Flows are visual workflows made from connected nodes. Use them when a ticket needs more than a simple button: ask questions, route by answer, call an external service, create a ticket with context, or run follow-up actions automatically.

Flow types

Interactive flows can ask users for input. Automation flows run without user prompts.

Build a flow

Node catalog

Node cards in the builder show the exact plan requirement. The groups are:

Interactive nodes

Collect input or show information during an interactive flow.

Action nodes

Change a ticket, message a channel, tag a role, set a variable, or wait before continuing.

Letting a button run out

A button posted by an automation flow stays in the channel, so by default anyone can press it as often as they like and the flow runs again each time. Give a button a click limit to cap that. Once the limit is reached the button either greys out or disappears, whichever you pick, and the flow can swap the message text for something else at the same time.

The count is per posted message and shared by everyone, so a limit of 1 makes a claim-once button: the first person to press it takes it. Leave the limit empty and the button keeps working indefinitely.

This applies to automation flows. An interactive flow already replaces its message at every step, so its buttons cannot be pressed twice.

How long a flow can wait

Three nodes pause an automation flow: Wait / Delay parks it on a timer, while Wait for Reply and Wait for Reaction suspend it until someone acts. Wait / Delay is available on Community and Pro; Wait for Reply and Wait for Reaction are Pro only.

One maximum covers whichever of the three your plan can use, and it comes from your plan. Community servers can wait up to

7 days, and Pro raises that to 30 days.

That is long enough for the usual follow-up pattern: ask the member for the missing details, wait a couple of days, nudge them, then close if the ticket is still quiet.

Saving a flow whose wait exceeds the maximum is rejected, so the builder always shows what the flow will actually do.

When a flow loops back on itself

A step wired back to an earlier one can send a run round the same circle over and over. A run that takes 50 steps in a row without any of them doing anything is stopped and marked abandoned.

Bad wiring often only breaks one way of starting the flow. A form step waits for a person, so the flow finishes when someone drives it from a panel, and the same flow can circle when it carries on by itself after a ticket is created, because nothing left in the circle can act without input. So the pause is per trigger: five circling runs on one trigger within 24 hours pause that trigger for 24 hours, and every other way of starting the flow keeps running. Switching the whole flow off would take the working path down with the broken one.

The server owner gets one DM naming the flow and the way of starting it that paused, in plain words rather than internal names. There is nothing to switch back on, since the pause lifts itself when the 24 hours are up, so fix where the last step points before then or it will pause again.

Advanced nodes

Compose flows out of other flow blocks.

Integration nodes

Call webhooks, external APIs, connected apps, or AI features.

Variables

Most text fields support double-brace variables, for example {{user.username}}.

Common variables:

When a ticket exists, a few more describe what has happened in it so far:

{{ticket.lastMessage}} skips the bot's own messages, and skips anonymous dashboard replies so they stay anonymous. If the newest message is one of those, it names the person who spoke before it. Each of these also has a .username and an .id form.

{{ticket.lastMessage.content}} is the text of that same message, and it is empty for an attachment-only reply. It is the right input for an AI node that should judge only what was just said. Leave an AI node's input blank and it reads the last ten messages instead, so it keeps matching on something raised earlier in the ticket.

The {{ticket.*}} variables are not limited to automation flows. A click-started flow gets them too whenever the click happened inside a ticket, which is what lets a workflow button reach the ticket's owner rather than the staff member who pressed it. They are empty in a flow that starts a new ticket, since none exists yet at that point.

Variable names are case-sensitive. If a placeholder appears unchanged in the final message, check that the variable exists earlier in the flow and that the spelling matches.

Seeing every variable while you debug

When a message comes out wrong and you are not sure what the flow actually collected, put {{all_variables}} in a step and run it. It prints every variable available at that point, one per line, with the full name on the left:

ticket.number = 42
ticket.status = OPEN
responses.Email = alice@example.com
responses.What happened? = Cannot log in after the update
api.login.user = alice
api.login.token = «redacted: looks like a credential»
custom._apiStatus = 200

That tells you the exact spelling to use, so a wrong guess like {{responses.email}} becomes an obvious {{responses.Email}}.

Three things to know:

• Values that look like credentials are hidden. Anything under a name like token, password, api_key or authorization is replaced with a redaction marker, as is any value shaped like a key or token even under an innocent name, and any token quoted inside a longer value such as an error body. Ordinary identifiers are left readable, so the ids in an API response still tell you what came back. This matters most for API Request steps, which can save a whole response body.
• It stays empty inside Send Webhook and API Request steps, so a token left in a flow by accident cannot send your run's data to an outside service.
• The output is capped in length and long values are shortened, so a large run will not overflow the message.

Import, export, and templates

Use Templates to start from common flow shapes such as ask-questions-first, route-by-topic, tag-staff, save-transcript, or warn-then-close.

Use the flow card action menu to Export as JSON. Use Import on the Support Flows page to create a new flow from an exported file. Server-specific IDs are not included, so imported flows still need to be linked to this server's panels, categories, channels, and roles.

Limits by plan

AI usage and limits

AI nodes require Pro. They share the server's monthly AI token budget, and the Plan & Billing page shows usage, limit, and reset date.

The reply nodes (AI Suggested Reply and AI Auto Reply) have an Include knowledge base switch that grounds the reply in published knowledge base articles and approved AI memory. It is on by default for new nodes, and a node saved without an explicit setting inherits the server-wide grounding default from AI Control. AI Auto Reply can post straight to the customer or run in draft mode, where staff review the reply with Send, Edit, and Discard buttons before anything reaches the customer. The AI Decision and AI Classify routing nodes have an opt-in Ground in knowledge + memory switch that adds the same retrieved context to their verdicts. See AI Assist for the reply modes in full.

If your server brings its own OpenAI-compatible provider key, AI runs on your provider account instead of the included platform budget. Plan limits for how many AI nodes a flow can use still apply.

Troubleshooting

Related

• Automation Rules
• Panels
• Categories
• Custom Commands
• Server Plans