After creating and publishing a Dynamic WhatsApp Flow, the next step is configuring the backend Dialogue Tree that powers the flow experience. The Dialogue Tree is responsible for controlling screen navigation, processing user actions, and returning dynamic data to WhatsApp Flow screens.

When a user interacts with a Dynamic Flow, WhatsApp continuously communicates with the configured bot application. Based on the current screen and user actions, the Dialogue Tree determines the next screen to display and returns any required payload data. This article explains how to configure the qualifying bot, use the required system fields, and build the Dialogue Tree logic for Dynamic WhatsApp Flows.

Config Bot Application Configuration

The bot application configured for the Flow is invoked whenever a user clicks the Call-to-Action (CTA) button associated with the WhatsApp Flow template.

Within the bot application:

• Create a Dialogue Tree that will handle all flow interactions.

• Mark this Dialogue Tree as the Qualifying Bot within the Config Bot Application.

For example, a Dialogue Tree named flows_configuration can be configured as the qualifying bot responsible for handling all Dynamic Flow requests. Once configured, every interaction within the WhatsApp Flow is routed through this Dialogue Tree.

System Fields Used in Dynamic Flows

Dynamic Flows rely on specific system fields to manage navigation and data exchange between Sprinklr and Meta.

GUIDED_WORKFLOW_SCREEN

This field identifies the current screen being processed. When a request is received from the Flow, the value of this field indicates which screen the user is currently viewing.

Examples:

• INIT

• FIRST_SCREEN

• SECOND_SCREEN

• OTP_SCREEN

• CONFIRMATION_SCREEN

The values should correspond to the Screen IDs defined within the Flow JSON.

GUIDED_WORKFLOW_NEXT_SCREEN

This field determines which screen should be displayed next. The value is typically set using an Update Properties node. Example:

GUIDED_WORKFLOW_NEXT_SCREEN = FIRST_SCREEN

After this value is returned, the Flow navigates to the specified screen.

GUIDED_WORKFLOW_RESPONSE

This field is used to send dynamic payload data back to Meta. The payload must be returned as a map containing all variables required by the target screen. This field is generally configured alongside GUIDED_WORKFLOW_NEXT_SCREEN within the same Update Properties node.

Example:

{
  "wrongOTPscreen": true,
  "errorMsgVisibility": true
}

The receiving screen can then use these values to dynamically render content, display messages, or control visibility of components.

INIT

When the Flow is launched, the value of GUIDED_WORKFLOW_SCREEN is always set to: INIT. This serves as the entry point for the Dynamic Flow journey. The Dialogue Tree must contain logic to handle the INIT path and determine which screen should be displayed first.

Building the Dialogue Tree

Step 1: Add a Decision Box

The first node in the Dialogue Tree should be a Decision Box that evaluates: GUIDED_WORKFLOW_SCREEN. This node acts as the central routing mechanism for the entire Flow. Each branch should correspond to a Flow Screen ID. Example branches:

• INIT

• FIRST_SCREEN

• SECOND_SCREEN

• THIRD_SCREEN

• FOURTH_SCREEN

As the user progresses through the Flow, the bot will repeatedly invoke the same Dialogue Tree and route execution through the appropriate branch based on the current screen.

FIRST_SCREEN

SECOND_SCREEN

FOURTH_SCREEN

Step 2: Configure the INIT Path

Since every Flow session begins with the value:

GUIDED_WORKFLOW_SCREEN = INIT

The INIT branch should contain logic that determines the first screen to display. Add an Update Properties node and set: GUIDED_WORKFLOW_NEXT_SCREEN = FIRST_SCREEN. This instructs WhatsApp to navigate to the screen with ID: FIRST_SCREEN. If no dynamic data is required, only the next screen value needs to be returned.

Step 3: Configure Screen-Specific Paths

Add an Update Properties node to each screen path in the Dialogue Tree.

In the Update Properties node, configure:

GUIDED_WORKFLOW_NEXT_SCREEN

Set the value of GUIDED_WORKFLOW_NEXT_SCREEN to the Screen ID that should be displayed after the current screen is processed.

Ensure that the configured value exactly matches the Screen ID defined in the Flow JSON.

For the INIT path, configure the first screen that should be displayed when the Flow is launched.

GUIDED_WORKFLOW_SCREEN = INITGUIDED_WORKFLOW_NEXT_SCREEN = FIRST_SCREEN

This routes the user from the Flow entry point to the screen with the ID FIRST_SCREEN.

Create a dedicated path for every screen that requires navigation to another screen.

When a user interacts with a screen, WhatsApp sends the current Screen ID through:

GUIDED_WORKFLOW_SCREEN

The Decision Box routes the request to the corresponding screen path.

In that screen path, configure GUIDED_WORKFLOW_NEXT_SCREEN with the Screen ID of the next required screen.

Example screen navigation configuration:

INIT pathGUIDED_WORKFLOW_NEXT_SCREEN = FIRST_SCREEN​FIRST_SCREEN pathGUIDED_WORKFLOW_NEXT_SCREEN = SECOND_SCREEN​SECOND_SCREEN pathGUIDED_WORKFLOW_NEXT_SCREEN = THIRD_SCREEN​THIRD_SCREEN pathGUIDED_WORKFLOW_NEXT_SCREEN = CONFIRMATION_SCREEN

To keep the user on the same screen, configure the current Screen ID as the next-screen value.

For example, if validation fails on OTP_SCREEN, configure:

GUIDED_WORKFLOW_NEXT_SCREEN = OTP_SCREEN

After configuring the next-screen value, add an End Dialogue Tree node to return the response to WhatsApp.

Step 4: Return Dynamic Payloads (Optional)

If a screen requires dynamic values, configure the GUIDED_WORKFLOW_RESPONSE field in the same Update Properties node. For example, assume the Flow contains a screen named: FOURTH_SCREEN. This screen expects the following variables:

• wrongOTPscreen

• errorMsgVisibility

In such a scenario: GUIDED_WORKFLOW_NEXT_SCREEN = FOURTH_SCREEN

GUIDED_WORKFLOW_RESPONSE:

{  "wrongOTPscreen": true,  "errorMsgVisibility": true}

When the Flow navigates to FOURTH_SCREEN, these values become available to the screen components and can be used to control the user experience dynamically.

Step 5: End the Dialogue Tree

After setting the required values:

• GUIDED_WORKFLOW_NEXT_SCREEN

• GUIDED_WORKFLOW_RESPONSE (if applicable)

Add an End Dialogue Tree node. This completes the current request cycle and returns the response to Meta.

Runtime Flow Execution

The Dynamic Flow does not invoke the bot only once. Throughout the user journey:

1. User opens the WhatsApp Flow.

2. The qualifying bot is triggered with GUIDED_WORKFLOW_SCREEN = INIT.

3. The Dialogue Tree returns to the next screen.

4. User interacts with the screen.

5. The Flow invokes the same qualifying bot again.

6. GUIDED_WORKFLOW_SCREEN is updated with the current screen ID.

7. The Decision Box routes execution to the corresponding path.

8. The Dialogue Tree returns the next screen and any required payload.

9. The process repeats until the Flow is completed.

Because every request is routed through the same Decision Box, the Dialogue Tree effectively becomes the controller for the entire Dynamic Flow journey.

Best Practices

• Ensure every Screen ID used in the Dialogue Tree exactly matches the Screen ID defined in the Flow JSON.

• Use a single Decision Box based on GUIDED_WORKFLOW_SCREEN as the central routing mechanism.

• Always set GUIDED_WORKFLOW_NEXT_SCREEN before ending the Dialogue Tree.

• Return only the payload variables required by the destination screen.

• Validate all dynamic data before sending it through GUIDED_WORKFLOW_RESPONSE.

• Add dedicated branches for error handling, validation failures, and alternate navigation paths to improve the user experience.