Intro to flows & variables

Flows and user intent

When communicating with your conversational AI, a user's intention can be as simple as getting an answer to their question or wanting to complete a series of tasks (e.g., cancel a flight, file an insurance claim, etc.). The user's goal or intent is handled by a flow, which defines the appropriate response or action your conversational application should follow.

An example of your conversational AI application at work:

• A user says, “I want to book a room”

• Using training data, an AI model recognizes "I want to book a room" as an expression that suggests the user's intent should match to the flow, BookRoom

• Your conversational application then responds by following the conversation logic defined within the BookRoom flow

Flow invocation

Flows are triggered in conversation in one of four ways:

• User invocation: Through the use of a User input node that captures a user's utterance and sends it to your application's AI model for intent recognition. When intent is recognized and is matched to a flow, the user is redirected to it (using an accompanying Redirect node set to Recognized flow). User choice nodes also support intent recognition and routing automatically in cases where user utterances don't match the assigned choices and new intent is detected

• Application default: When assigned to one of the available default behaviors, a flow is invoked during certain events the NLX NLU tracks (the start of a conversation session, fallback/failure events, unrecognized intent and therefore unmatched flows, etc.)

• Redirect node: When deliberately directed to via a Redirect node in another flow

• MCP extension: When a flow is exposed to an LLM client via Model Context Protocol, the LLM invokes it as a tool when user intent is matched

How flows are defined in NLX

The core functionality of flows are comprised of the following:

• Nodes: Carefully sequenced across the Canvas builder of a conversation flow, nodes represent a single step executed in a turn

• Turn: A single exchange between the conversational AI and the user. A turn stops when a specific node is reached (either a User choice/input node, Generative Journey node, or node that is disconnected to any subsequent node)

• Flow name: A brief descriptive name for the flow that an NLP engine uses when constructing the stack of flows that make up your conversational application. Must be unique and must avoid spaces or special characters (e.g., BookRoom)

• AI description: Context on the purpose of the flow so an LLM model understands when to invoke the flow through user intent recognition

• Training phrases: A sample of phrases (utterances) users might say so an NLP model understands when to invoke the flow

• Variables: Pieces of information that are required to successfully complete the flow and may be extracted from the user or defined from data gathered externally

• External actions: Events triggered that send or retrieve data outside NLX. These may be triggered via Data request, Generative Journey, or Action nodes

Variables in flows

Every conversation between your application and a user is unique with details that change from session to session based on user choices, context, and external or generated data that changes in real time. Since this information can't be hardcoded into your flow's messaging or logic, variable placeholders are used to handle it dynamically.

To reference variables created, you may bring up the placeholder menu in supported text fields of your flow using an open curly brace {:

Each dynamic placeholder (variable) is distinguishable by color:

• Purple: Local flow variables or Built-in integrations and their variables

• Green: Custom or built-in Slots

• Orange: Data requests and their data variables

• Pink: Context variables, Secrets, or MCP inputs

• Light teal: System variables

List of System variables

NLX system variables are helpful when referenced in conditional logic in Split nodes, adding dynamic placeholders in messages, or providing context to Generative nodes for more tailored responses.

To use a system variable while configuring a node, type an open curly brace { and start typing system to choose from the available options.

Capturing variables from users

Slots are used to extract specific information from the user, especially if the variables are custom and static (e.g, yes/no, small/medium/large, etc.) or if the variables are abstract or infinite in range (e.g., time, cities, names). They may be used in training data to better route to flows or asked by the conversational AI when assigned to User choice or Generative Journey nodes.

In a BookRoom flow, for example, variables that need to be resolved could include check-in and check-out dates, room type, number of guests, etc.

In the sample utterance, "I want to book a King room for Saturday," two variables are given by the user: room type and check-in date. These variables can be captured using a custom slot type named {RoomType} and a built-in date slot named {CheckInDate}.

Externally defined

For variables that must first be fetched externally in real-time to provide to users as options or to relay dynamic data, Data request nodes are used.

For example, with a BookRoom flow, available room types can be retrieved from a Data request node and then presented in a User choice node, since these variables are likely to change regularly.

Additional methods for passing variables from another system to NLX, include:

• Lifecycle hook: Passes variables captured from a system or channel provider to NLX (at the time your conversational application is called) through the use of context. Must assign the Lifecycle hook created to the application's start lifecycle

• MCP input: Passes variables captured from an MCP Client (LLM service) to NLX when the LLM invokes the flow. Must have MCP setup completed for your application