> For the complete documentation index, see [llms.txt](https://atlas.anywhere.now/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://atlas.anywhere.now/contact-center-configuration/building-your-callflow/via-dialogue-studio/dialogue-manager-and-message-flow-nodes.md).

# Use message-flow nodes in Dialogue Studio

Use Dialogue Studio message-flow nodes to receive chat messages, respond, wait for the next input, queue the session, or end the interaction.

Use this page when a Dialogue Studio flow starts from a configured chat or message entry path instead of from an audio call and must respond, wait, queue, or disconnect by using message-flow nodes.

## Before you begin

* Confirm that the chat or message entry path for the target flow is already configured for the environment.
* Confirm that any required connection or authentication values for that entry path are stored in the approved configuration surface.
* Confirm that the target flow can pass the session state and required message values to the next node.
* Plan to validate the message path in a controlled test flow before you expose it to production traffic.

{% hint style="warning" %}
Message-driven flows depend on a consistent chat-session state across multiple steps. Validate the wait, queue handoff, and disconnect behavior before you rely on this flow pattern in production.
{% endhint %}

## Start with the configured chat or message entry path

Use the configured chat or message entry path when the flow starts from a message request rather than from an audio conversation.

Keep the entry pattern simple:

1. Receive the request through the configured endpoint.
2. Extract the payload that the rest of the flow needs.
3. Pass the session state and required message values to the downstream nodes.
4. Route to the next action, wait, or end step based on the result.

## Use response and end nodes together

Most message-flow designs depend on a small set of reusable node responsibilities.

### Use **Say** for the response content

Use **Say** when the flow must return or present message content to the participant.

Before go-live, confirm:

* which output text the flow should return
* whether the response depends on the current message context
* whether the next step should wait for another message or end the interaction

### Use **Wait for Chat** to continue the same conversation

Use **Wait for Chat** when the next incoming message should continue the existing chat session instead of starting a new conversation.

When you use this pattern:

* preserve the session state and message values that the next step needs
* confirm how long the conversation can wait for the next message
* confirm what happens when no next message arrives

### Use **Enqueue** when automation should stop

Use **Enqueue** when the automated message path should hand the conversation to a configured queue or skill.

Before you use it:

* confirm which queue or skill should receive the conversation
* confirm what data the queue handoff requires
* confirm what the flow should do if the handoff does not succeed

### Use **Disconnect** to end the interaction

Use **Disconnect** when the message interaction should end without another wait step or queue handoff.

Keep the disconnect path explicit so the conversation does not stay open by mistake.

## Keep the message state consistent

Message-flow nodes depend on the same chat session being carried through the intended state changes across multiple steps.

Good practice is to:

* keep the initial session payload small and predictable
* pass only the fields that the next step needs
* confirm that wait, queue, and disconnect paths all receive the expected session state
* test one success path and one timeout or failure path for the same conversation

## Verification

1. Confirm the incoming message trigger receives the expected payload from the configured entry point.
2. Confirm the **Say** node returns the intended response content.
3. Confirm the **Wait for Chat** path resumes the same conversation with the expected session state.
4. Confirm the **Enqueue** path hands the interaction to the intended queue or skill.
5. Confirm the **Disconnect** path closes the interaction cleanly when the flow should end.

## Related topics

Go to **Apply Dialogue Studio scenario patterns** for reusable fallback, branch, and recovery patterns that can extend message-driven flows.

{% content-ref url="/pages/1aeml1BpvC79ocfNQlEt" %}
[Apply Dialogue Studio scenario patterns](/contact-center-configuration/building-your-callflow/via-dialogue-studio/apply-dialogue-studio-scenario-patterns.md)
{% endcontent-ref %}

Go to **Troubleshoot Dialogue Studio** for payload-shape and runtime-error checks when a message-driven branch does not continue as expected.

{% content-ref url="/pages/1DZ33M6NXFEl7w5wpxlG" %}
[Troubleshoot Dialogue Studio](/contact-center-configuration/building-your-callflow/via-dialogue-studio/troubleshoot-dialogue-studio.md)
{% endcontent-ref %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://atlas.anywhere.now/contact-center-configuration/building-your-callflow/via-dialogue-studio/dialogue-manager-and-message-flow-nodes.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.