Overview

Control Flow blocks in the Conversation Process enable developers to define the logic and decision-making processes for conversational plugins. These blocks work alongside Activities to create workflows that mirror business processes.

Conversation Process Decision Policy

What is a Decision Policy?

A Conversation Process Decision Policy executes a set of process blocks based on whether a condition, defined using a DSL expression, evaluates to true. It emulates human decision-making by directing the AI agent’s workflow according to predefined rules.

Use Case Example

For a flight booking plugin, your organization may require:

• If the flight is booked ≥ 7 days in advance: The Assistant books the flight directly.
• If booked < 7 days in advance: The Assistant collects approval from a manager before booking.
• If booked < 3 days in advance: The Assistant instructs the user to book with a personal card and submit a reimbursement request.

Pattern: Action → Decision Policy → Branch

The most common workflow in a conversation process is call an API, branch on its result. The pieces exist (Action Activities, Decision Policies, the data bank) but they compose in a specific order that isn’t always obvious:

1. An Action Activity calls an API and stores the result in the data bank via its Output Mapping.
2. The Decision Policy evaluates DSL against that stored data.
3. Each case branches the process into the right path.

Put differently — the API call runs first, as its own activity. The Decision Policy only reads data that’s already in the data bank. You cannot put an API call inside a Decision Policy condition.

Worked example: room booking

Given an HTTP action check_room_availability that returns {"available": true, "alternatives": [...]}, the conversation process is wired up as:

Step 1 — Action Activity

Step 2 — Decision Policy

1
# Case 1: Room is available
2
data.availability_check.available == true
3
4
# Case 2: Room is not available
5
data.availability_check.available == false

Step 3 — Branch steps

• Case 1 path: Action Activity that books the room.
• Case 2 path: Content Activity that surfaces data.availability_check.alternatives to the user.

Anatomy of a Decision Policy

Required Slots

Specify the slots that must be collected before evaluating the decision policy. These ensure the AI has the necessary data to make informed decisions.

Cases

Each case defines a condition using a DSL expression. If the condition evaluates to true, the associated process blocks are executed.

Example: Referencing Slot Values

To evaluate a slot named asana_project, use the following DSL syntax:

1
# data.<slot_name>.value == "<project_name>"
2
3
data.asana_project.value == "ProjectX"

This checks if the asana_project slot equals “ProjectX” and directs the workflow accordingly.

Example: Flight Booking Policy

1
# Case 1: Flight is ≥7 days away
2
$PARSE_TIME(data.travel_date.value) >= $TIME().$ADD_DATE(0, 0, 7)
3
4
# Case 2: Flight is <7 days but ≥3 days
5
$PARSE_TIME(data.travel_date.value) < $TIME().$ADD_DATE(0, 0, 7) AND $PARSE_TIME(data.travel_date.value) >= $TIME().$ADD_DATE(0, 0, 3)
6
7
# Case 3: Flight is <3 days
8
$PARSE_TIME(data.travel_date.value) < $TIME().$ADD_DATE(0, 0, 3)

Default

The Default branch defines the process blocks to execute if none of the case conditions evaluate to true. This ensures the process always has a fallback path.

Example: Default Branch

# If no conditions match, display a message
Content Activity: "Sorry, your request cannot be processed. Please contact support."

Exit Block

The Exit Block terminates the entire plugin execution immediately. It is used to stop the workflow when a specific condition is met, preventing further processing.

Use Case: Use an Exit Block in a decision policy branch to halt the plugin, such as when an invalid input is detected or a process cannot proceed.

# Decision Policy
Case: data.priority == "High" -> Run Action Activity
Case: data.priority == "Invalid" -> Exit Block (terminate plugin)
Default: Content Activity: "Please specify a valid priority."

Continue Block

The Continue Block allows the plugin to proceed to the next process block in the conversation process, continuing execution without interruption. It is useful in decision policy branches where you want the plugin to move forward with subsequent actions rather than stopping.

Use Case: Use a Continue Block in a decision policy branch to ensure the plugin continues processing after handling a specific condition, such as logging an event before proceeding.

# Decision Policy
Case: data.user_role.value == "admin" -> Run Action Activity -> Continue Block (proceed to next steps)
Case: data.user_role.value == "guest" -> Content Activity: "Access denied." -> Exit Block
Default: Content Activity: "Invalid role. Please try again." -> Continue Block