Control movement with routes and conditions

Learning objective

Control workflow movement with transition routes and conditions. This lesson assumes pages already define meaningful states and focuses on how handlers move the session between them.

Core idea

A transition is a guarded state change:

handler is in scope + requirement is satisfied -> fulfillment + target state

Use an intent route when movement depends on what the user means. Use a condition route when movement depends on trusted state. A route may also produce fulfillment without moving, or move without producing a response.

How it works

In Dialogflow CX, a state handler has requirements, optional fulfillment, and an optional transition target. A route is called when its intent requirement, its condition requirement, or both are satisfied. If both exist, both must be satisfied. Google Cloud documents these mechanics in State handlers.

Choose the route type from the decision input:

• Use an intent requirement for language such as “cancel this order” or “choose express shipping.”
• Use a condition requirement for state such as $session.params.total >= 500 or completion of all required form parameters.
• Combine them when the user intent is valid only under a specific state, such as confirming a purchase only after a quote exists.

Put a route at page scope when it is meaningful only on that page. Put an intent route at flow scope when it should remain available through the active flow, such as a request for help or cancellation. Flow-scoped intent routes are evaluated throughout the active flow. In contrast, flow-scoped condition routes are evaluated only when the current page is the flow start page. Put a condition that must be checked on every page on those pages, or reuse it through a page route group. Confirm the precise handler scope and evaluation order because multiple in-scope handlers may qualify.

Ordering matters. Intent routes are evaluated before condition-only routes. An intent is normally consumed after the first matching route is called. Conditions are not consumed, so more than one satisfied condition handler can run when the earlier handler has no transition target. A called handler with a transition target ends evaluation of the remaining handlers in the current list, including the remaining evaluation phases for that page. The session then moves to the target page, where entry fulfillment and handlers are evaluated in the same conversational turn. Write mutually exclusive conditions when only one branch should be possible.

Use fulfillment for work associated with the transition, but do not let the graph claim success before an external operation confirms it. For example, a webhook can request an order, and its result can set a session parameter. A later condition route moves to Order confirmed only when the result is successful.

Treat unconditional routes carefully. A condition that is always true is useful for a deliberate default transition. Because evaluation continues on each target page in the same turn, two pages that unconditionally target each other create an execution loop. Each automatic transition chain needs a terminal wait, completion state, or bounded failure path.

Key distinctions and trade-offs

Requirement versus target: A requirement decides whether a handler is called. The target decides where the session moves. A handler can respond without a target and remain on the active page.

A target moves the session and restarts evaluation there in the same turn; without one, the session remains on the active page.

Intent versus condition: Intent matching is probabilistic interpretation of user input. A condition evaluates state. Do not build an intent merely to express a known boolean business rule.

Route versus event handler: Routes respond to intent and state conditions. Event handlers respond to events such as no input, no match, or webhook failure. Both may transition, but their triggers differ.

Global routes reduce duplication but can match where an action is unsafe or nonsensical. Page routes provide precise context but can duplicate common behavior. Use the narrowest scope that covers all valid states.

Architecture / decision scenario

An insurance claim flow has a Review claim page. The user can express a Confirm submission intent. That route also requires $session.params.review_complete = true. Its fulfillment calls the submission webhook but does not immediately target the completed page.

The webhook sets submission_status. A condition route moves to Submitted when the value is SUCCESS. Another route moves to Submission assistance for a non-retryable failure. A flow-scoped Cancel intent remains available until submission succeeds.

This separates semantic confirmation, structured readiness, and actual backend outcome. A matched confirmation alone cannot submit an incomplete claim or misreport a failed operation.

Common exam traps

• Using an intent route for a decision already represented by trusted state.
• Assuming a matching intent is enough when a required condition is also present.
• Forgetting that a route can fulfill without transitioning.
• Writing overlapping condition routes as if only the first can run in every configuration.
• Expecting a flow-scoped condition route to run beyond the flow start page.
• Putting a sensitive action on a broadly scoped route.
• Adding unconditional transitions without checking for automatic cycles.

What to remember

• Intent routes react to meaning; condition routes react to state.
• Scope routes to the states in which their actions are valid.
• Treat fulfillment success and state transition as separate decisions.
• Account for documented handler evaluation order and intent consumption.
• Make automatic transitions mutually exclusive and terminating.

Knowledge check

References

• Google Cloud, State handlers
• Google Cloud, Conditions
• Google Cloud, Pages
• Google Cloud, Fulfillment