On User Input
Runs on every user message – pre-process input before it reaches your Conversational Flows.
The On User Input handler fires every time the user sends a message – whether typed text or transcribed voice. It is the most commonly customized handler and serves as the pre-processing layer for all user-driven interactions.
When It Runs
This handler runs before any Conversational Flow processes the message. The user's message is available as context throughout the handler, but no response is sent to the user until a flow node generates one.
Common Uses
- Language detection – Use
Detect Text Languageto identify the language of each incoming message, then route accordingly - Variable pre-checks – Read a variable (e.g., GDPR consent status) and branch logic before any flow runs
- Input filtering – Use
Abandon Processingto silently drop messages that don't meet certain criteria (via intent Matcher) - Flow routing – Use
Activate Flowto jump directly to a specific flow based on the input, bypassing the default flow routing
Typical Node Pattern
The simplest production-ready On User Input handler looks like this:
Text Handler Entry
│
├── On First User Input ──► [initialization logic] ──► Continue Processing
│
└── On User Input ──► Detect Text Language ──► Continue ProcessingThe Text Handler Entry node (the entry point) exposes two branches:
- On First User Input – Only fires on the very first message of a session. Use this to run one-time initialization.
- On User Input – Fires on every subsequent message.
Available Nodes
All standard context, logic, and integration nodes are available. Handler-specific nodes include:
| Node | Category | Purpose |
|---|---|---|
| Detect Text Language | Preprocessing | Identifies the language of the incoming text |
| Continue Processing | Exit | Passes control to Conversational Flows |
| Abandon Processing | Exit | Drops the message – no response is generated |
| Activate Flow | Exit | Triggers a specific Conversational Flow directly |
| Check Variable | Context | Reads a variable value for conditional logic |
| Store Variable | Context | Writes a value to a user or conversation variable |
| Find record(s) | Context | Queries a data table |
| EPC Tag Decode | Context | Decodes an RFID/NFC EPC tag value |
| Route by Profile | Logic | Branches by touchpoint (Web Widget vs. Kiosk) |
| Route by Language | Logic | Branches by current active language |
| Route by Signal | Logic | Branches by a named signal |
| Intent Matcher | Logic | LLM-powered intent routing |
| Is Flow Active | Logic | Checks if a specific flow is currently running |
| Trigger Automation | Integration | Fires an Automation flow |
| Comment | Other | Adds a note to the canvas (no logic) |
Example: Language Detection + Continue
The most common pattern detects the user's language and triggers an automatic language switch if needed:
- Text Handler Entry – entry point for all user messages
- Detect Text Language – analyzes the text and sets the detected language
- Continue Processing – passes the (now language-enriched) message to flows
This ensures every incoming message has its language identified before the Conversational Flows process it.
Example: GDPR Gate
Check whether the user has given GDPR consent before routing to any flow:
- Text Handler Entry
- Check Variable (
{{variable.gdpr}}) – branch: consented / not consented - Branch A (consented) → Continue Processing
- Branch B (not consented) → Activate Flow (GDPR consent flow)
The Activate Flow node at the end of a Handler branch works differently from the Go to Flow node inside a Conversational Flow. In a Handler, Activate Flow triggers the target flow and then the Handler's execution ends – no Continue Processing is needed after it.