Intent Classification

Overview

The Intent Classification node is a specialized Integration Designer workflow node that combines AI-powered message classification with workflow branching in a single node. It analyzes a user message, classifies it into one of your defined intents using an LLM, and automatically routes the workflow to the matching branch — replacing the previous two-node pattern (TEXT_UNDERSTANDING + Condition).

Intent Classification Agent node with intents list and the If No Intent Matches default branch

The Intent Classification node is available in Integration Designer workflows alongside other node types like REST Endpoint, Script, Condition, and Custom Agent. For BPMN process workflows, use the Start Integration Workflow action to invoke workflows that contain Intent Classification nodes.

AI + routing in one node

Combines LLM classification and conditional branching — no separate Condition node needed

Natural language conditions

Define intents as plain-text descriptions instead of code expressions

Conversation memory

Optionally use past conversation context for more accurate classification

Built-in fallback

Automatic “If No Intent Matches” branch handles unrecognized inputs

How it compares to the pattern approach

Aspect	Pattern (TEXT_UNDERSTANDING + Condition)	Intent Classification node
Nodes required	2 (classify, then route)	1 (classify and route)
Conditions	Python/JavaScript expressions	Natural language descriptions
Max branches	Unlimited	10 intents + fallback
Response schema	Manual JSON schema	Automatic (handled internally)
Rationale	Must be added to prompt manually	Built-in toggle

Configuration

Open your workflow

Open your workflow in Integration Designer.

Add the node

Add an Intent Classification node from the AI Agents category in the left panel.

Configure the user message

Set the User message field to the input text that should be classified. Use ${} syntax to reference workflow data keys.

Define intents

Add intent descriptions — each intent becomes a separate output branch on the node.

Connect output branches

Connect each intent branch and the fallback branch to downstream nodes in your workflow.

Personal Information Guard

For the full reference — sensitivity presets, the complete entity catalog, scan flow, and run-log fields — see Personal Information Guard.

Personal Information Guard

boolean

Detects and replaces personal data in messages before they reach the model. A system instruction is automatically added so the agent handles redacted content naturally.Default: OFFWhen turned on, the following sub-options become available:

Detection Algorithm Sensitivity — One of Strict, Balanced (default), Relaxed, or Custom. Controls how aggressively the detector flags potential matches.
Detection Target — Check Node Input, Node Output, or both to choose which payloads are scanned.
Personal Info Types — Opens the Customize Entities modal, the picker for which of the 24 supported entity types (Universal + Regional EN + Regional RO) should be detected. All 24 are enabled by default. See the Extract Data from File reference for the full entity list.

User Message

string

required

The text input to classify. Use ${} syntax to reference workflow data keys.Example: ${userMessage}

Reference a workflow data key that contains the user’s message rather than hardcoding text. This allows the node to classify different messages at runtime.

Use conversation memory

boolean

When turned on, the node sends the session ID to the AI platform and appends conversation history to the LLM call. This provides context from past messages for more accurate classification. See Memory Capabilities for details on how memory retrieval works.Default: OFF

Turn on memory when classifying messages in multi-turn conversations where context matters — for example, distinguishing “yes” (confirming a previous offer) from “yes” (answering a question).

Intents

intentClassificationOptions.conditions

array

required

A list of intent descriptions that define the classification categories. Each intent becomes an output branch on the node.

Minimum: 1 intent + fallback
Maximum: 10 intents + fallback
Each intent description can be up to 3 lines of text
The If No Intent Matches fallback branch is always present and cannot be removed

Example intents:

Intent	Description
Intent 1	The user is asking about product features, pricing, or availability
Intent 2	The user wants to update their personal information or submit documents
Intent 3	The user is greeting or making small talk
Fallback	If No Intent Matches

For best accuracy, classify up to 10 intents per node. If you need more intents, chain multiple Intent Classification nodes to narrow down in stages.

Response key

responseKey

string

required

The key where the classification result is stored in the workflow data.Example: classificationResult

Include Reason for Selection

intentClassificationOptions.includeRationale

boolean

When turned on, the agent includes a rationale explaining why it chose this intent in its response.Default: OFF

Turn on rationale during development and testing to understand classification decisions. You can turn it off in production to reduce response size.

Output

The node stores its classification result under the configured Response key in the workflow data. The output contains:

Field	Type	Description
`selected_intent`	string	The description text of the matched intent
`selected_branch`	number	The branch number (1–11) corresponding to the matched intent
`rationale`	string	Explanation of why the LLM chose this intent (only when Include Reason for Selection is ON)

Example output:

{
  "selected_intent": "The user is asking about product features, pricing, or availability",
  "selected_branch": 1,
  "rationale": "The user asked 'How much does the premium plan cost?' which is a direct inquiry about pricing."
}

Workflow routing

After classification, the node routes the workflow token to the matching branch:

Intent branches — the workflow continues along the branch whose intent description matched the user message
If No Intent Matches — the fallback branch activates when the LLM response doesn’t match any defined intent

This routing works like a Condition (Fork) node, but conditions are evaluated by the LLM using natural language instead of code expressions.

Examples

Customer support routing

Scenario: Route customer messages to specialized support handlers.Intents:

The customer is reporting a technical issue or bug
The customer is asking about billing, payments, or invoices
The customer wants to cancel or modify their subscription
The customer is asking a general question about the product

Fallback: Routes to a human agent handoff workflow.Each branch connects to a specialized handler — for example, the billing branch triggers a workflow that looks up the customer’s invoice history, while the technical issue branch creates a support ticket.

Banking chatbot

Scenario: Classify banking customer requests in a chat-driven workflow.Intents:

The user wants to check their account balance or transaction history
The user wants to transfer money or make a payment
The user is asking about loan or mortgage options
The user is greeting or making small talk

Configuration:

Use conversation memory: ON (to understand context in multi-turn conversations)
Include Reason for Selection: OFF (production deployment)

The balance branch queries the account API, the transfer branch starts the payment workflow, and the loan branch triggers a knowledge base lookup.

Email triage pipeline

Scenario: Classify incoming emails and route to appropriate processing.Intents:

The message is a complaint or escalation requiring urgent attention
The message is a new business inquiry or sales lead
The message is a support request with a reference to an existing ticket
The message is informational (newsletter reply, out-of-office, automated notification)

Fallback: Routes to a manual review queue.Configuration:

Use conversation memory: OFF (each email is independent)
Include Reason for Selection: ON (for audit trail)

Best practices

Write specific intent descriptions

Describe each intent clearly and distinctly. Vague or overlapping descriptions reduce classification accuracy.

Chain nodes for complex taxonomies

For more than 10 categories, use a first node to classify into broad groups, then a second node to classify within each group.

Always handle the fallback

Connect the fallback branch to meaningful handling — a clarification prompt, a human handoff, or a default response.

Use rationale for debugging

Turn on Include Reason for Selection during development to understand why the LLM routes to unexpected branches.

Integration Designer

Learn about Integration Designer workflows and all available node types

AI node types

Overview of all AI node types in Agent Builder