All Products
Search

This Product

    Chat App Message Service:Natural Language Dialogue

    Document Center

    Chat App Message Service:Natural Language Dialogue

    Last Updated:Jun 21, 2026

    This component sequentially receives and processes mobile originated (MO) messages (user inputs) during interactions with a large language model (LLM). It ensures each input is passed to the LLM in order, using the conversation context to generate coherent responses and maintain the continuity of multi-turn conversations.

    Component information

    Icon

    Name

    image.png

    Natural Language Dialogue

    Prerequisites

    To configure this component, access the flow canvas by using an existing flow or creating a new one.

    • Go to the canvas of an existing flow

      In the Chat Flow > Flow Management > Flow Name

    • Create a new flow to open its canvas. For more information, see Create a flow.

    Procedure

    1. On the canvas, click the Natural Language Dialogue component icon to open its configuration panel on the right.
      In the chat flow canvas, a flow consists of Start, Natural Language Dialogue, and End nodes. Select the Natural Language Dialogue node. In the configuration panel, set the model parameters. For example, set Implementation Type to Model and Protocol to OpenAI. Then, enter the baseUrl (for example, https://api.demo.com/v1), the API key, and the Model Name. In the Initial prompt text area, enter a system role description.

    2. Configure the component as needed. For detailed parameter descriptions, see the Configuration section.

    3. After you finish the configuration, click Save. In the dialog box that appears, click Save.

    Configuration

    1. Model settings

    Click Implementation Type and select either Model or Application. Parameters vary by selection.

    Model

    Parameter

    Description

    Protocol

    Only OpenAI is supported when the implementation type is Model.

    baseUrl

    The model service endpoint, such as https://api.openai.com/v1 or any OpenAI-compatible URL.

    apiKey

    The API key for the model service.

    Model Name

    The name of the model to use, such as gpt-3.5-turbo or qwen-plus.

    Initial Prompt

    Sets the context for the model session and guides output. Example: "You are a witty comedian. Use humorous language in your responses."

    Model Input

    Input for the current conversation turn. Reference variables directly or embed them in text, such as {{incomingMessage}} or Please find information about {{topic}}.

    Model Output Variable Name

    Variable name for the model output. Use in subsequent steps or as a reply.

    Fallback Text

    Output when the model service is unavailable. Example: "Sorry, I am unable to answer your question at the moment."

    Application

    Parameter

    Description

    Protocol

    Only Dashscope is supported when the implementation type is Application.

    Note

    Learn how to build applications in Application development.

    apiKey

    The API key for the application service.

    workspaceId

    The workspace ID containing the application (agent or workflow). Required for sub-workspaces; optional for the default workspace.

    appId

    The application ID.

    Application Input

    Input for the current conversation turn. Reference variables directly or embed them in text, such as {{incomingMessage}} or Please find information about {{topic}}.

    Custom Pass-through Parameters

    Custom parameters passed to the application, such as {"city": "Hangzhou"}.

    Application Output Variable Name

    Variable name for the application output. Use in subsequent steps or as a reply.

    Fallback Text

    Output when the application service is unavailable. Example: "Sorry, I am unable to answer your question at the moment."

    2. Request header configuration

    Note

    Request header configuration is not supported when the Implementation Type is set to Application.

    Parameter

    Description

    request header

    HTTP request header settings. Enter the following information:

    • Key

    • Value

    3. Message settings

    Configure message delivery after the LLM generates a response.

    Parameter

    Description

    Channel

    The channel for sending messages.

    Note

    Currently, only WhatsApp channels are supported.

    Enable WhatsApp typing indicator

    Displays a typing indicator in the current conversation to inform the user that a response is being prepared.

    Action

    The message action. Currently, only "reply" is supported, which sends a reply to the user's mobile originated (MO) message.

    Message Type

    The type of message to send. Currently, only plain text replies are supported.

    long message splitting

    Splits a long message generated by the LLM into multiple shorter messages based on a specified delimiter.

    • Do not split: Sends the model's response as is.

    • Split by newline character: Splits the message using the newline character (\n).

    • Custom: Splits the message by using a custom delimiter that you specify in the input box.

    Message sending interval

    This is only available when long message splitting is enabled. It sets the delay between sending each part of a split message.

    • Fixed interval: The system sends the split messages at a fixed interval you define. You must enter a time in the interval input box.

    • Smart interval: The system simulates human typing by automatically calculating the sending interval based on the character count of each split message. Longer messages have a longer delay.

    4. Timeout settings

    Parameter

    Description

    Waiting Time

    The timeout period for waiting for a mobile originated (MO) message from the user. If this time is exceeded, the multi-turn conversation automatically ends. Currently, a session can only be ended by a timeout; it cannot be closed manually.

    Natural Language Dialogue vs. Natural Language Generation

    Both components use a large language model (LLM) to automatically generate intelligent content and respond to user messages. However, they differ in their message-handling mechanisms and use cases:

    • The Natural Language Dialogue component is designed for multi-turn conversations. When a user sends an MO message, the component submits it to the LLM to generate a response. If the user sends more messages while the model is processing, these new messages are not discarded. Instead, they are placed in an internal queue. After the model completes its current response, the queued messages are processed in order, ensuring the continuity and integrity of the conversation's context.

    • The Natural Language Generation component is ideal for single-turn, context-independent tasks. It passes variables from the flow (such as user input or system parameters) to the LLM to generate a one-off response. The result is then returned to the business flow for subsequent use or delivery. This component processes only the most recent MO message and does not queue any new messages that arrive during processing.

    Aspect

    image.pngNatural Language Generation

    image.pngNatural Language Dialogue

    Component role

    Passes variables defined in the flow to the LLM to generate a response. The response is then returned to the component for delivery or use in subsequent nodes.

    • Sends a user's MO message to the LLM to generate a response.

    • Queues any new MO messages received while waiting for the response. After the first response is sent, the component sends the queued messages to the model for subsequent replies.

    Scope of input processing

    Processes only the most recent MO message received after the model has replied.

    Processes the initial MO message and then continues to process all MO messages that were queued while the first response was being generated.

    Handling of new MO messages during response generation

    Ignored (not processed).

    Queued (held for processing in a later batch).

    Interaction model

    Single-turn generation with a fixed, predictable flow.

    Continuous conversation that can handle consecutive user statements.

    User experience characteristics

    More stable and controllable.

    User interruptions do not affect the current generation cycle.

    Feels more like a human conversation.

    Ensures no user input is missed.

    Typical uses

    Explaining, summarizing, rewriting, or converting structured information into natural language.

    Continuous Q&A, handling follow-up questions, processing supplemental information, and other multi-turn conversations.

    Use cases

    Process-driven scenarios that require strict control and fixed steps, and where interruptions from multi-turn queuing are not desired:

    • Explaining order, ticket, or logistics status

    • Confirming summarized information

    • Generating scripted responses at fixed nodes in a flow

    • Generating text based on variables

    Dialogue-heavy scenarios where users often send messages in quick succession and expect every message to be processed:

    • Pre-sales inquiries

    • Usage guidance

    • Handling frequent, consecutive follow-up questions

    • Scenarios where users tend to send multiple short messages at once