Pages Stay organized with collections Save and categorize content based on your preferences.

A Dialogflow CX conversation (session) can be described and visualized as a state machine. The states of a session are represented by pages.

For each flow, you define many pages, where your combined pages can handle a complete conversation on the topics the flow is designed for. At any given moment, exactly one page is the current page, the current page is considered active, and the flow associated with that page is considered active. Every flow has a special start page. When a flow initially becomes active, the start page becomes the current page. For each conversational turn, the current page will either stay the same or transition to another page.

You configure each page to collect information from the end-user that is relevant for the conversational state represented by the page. For example, you might create the pages (in blue) in the diagram below for a Food Order flow of a pizza delivery agent. The Start node of the diagram represents the start page of the Food Order flow. When the flow is complete, it transitions to the Confirmation flow.

[Example multi-flow diagram.]

Lifecycle of a page

Once a page becomes active, the agent follows several steps which may involve entry fulfillment, prefilling forms, state handler evaluation, form parameter prompting, sending response messages to the end-user, and either a page change or a repeat loop:

[Page lifecycle diagram.]

The details of this process are as follows:

1. If entry fulfillment exists for the page, it is called. Any static responses provided by fulfillment are added to the response queue.

   If partial response is enabled, Dialogflow CX flushes the response queue and sends all queued messages as a partial response to the streaming API caller.

   If the fulfillment has a webhook, the webhook is called, which may append additional responses to the queue. These additional responses do not trigger an immediate flush of the response queue.

2. If the page has form parameters, they may be pre-filled:

   • Any set session parameter with the same name as a form parameter is copied to the form parameter.
   • If a route triggered a transition to this page, and the route contains a matched intent, any intent parameter with the same name as a form parameter is copied to the form parameter.

3. If any state handlers are in scope, they are evaluated according to the handler evaluation order rules. This can involve routes, event handlers, or reprompt handlers invoked from the prior loop iteration. If any state handler is called, one or both of the following may happen:

   • If fulfillment exists for the handler, it is called. Any static responses provided by fulfillment are added to the response queue. Partial response and webhook are also executed if they are enabled.
   • If a target flow or page exists for the handler, the session transitions to the target and the page becomes inactive.

4. If all of the following are true, a form parameter prompt is added to the response queue:

   • The page has a form.
   • There are required form parameters left to fill.
   • A reprompt handler was not followed in step 3.
   • Partial response and webhook are executed if they are enabled.

5. The remaining response queue messages are sent to the end-user, and the agent waits for end-user input.

6. If end-user input provides a prompted form parameter, fill the parameter. Continue to step 3.

Page lifecycle navigation

The simulator execution steps viewer allows you to switch between the steps for a specific conversation turn and brings the related agent builder elements into focus for each step. In the following example, end-user input "I would like to rent a car" triggers five execution and transition steps:

1. The executions steps viewer brings you to conversation starting page for the first step. In this case it's the default start page. [Page execution step 1.]

2. Transition route for the intent car_rental.reservation_create is triggered. The executions steps viewer brings this route to focus, where you can see that the transition target is the Pickup Location page. [Page execution step 2.]

3. Agent enters page Pickup Location. [Page execution step 3.]

4. Agent evaluates the entry fulfillment of Pickup Location page. The fulfillment is empty, so nothing happens. [Page execution step 4.]

5. Agent tries to collect the required form parameter pickup_location and the initial prompt fulfillment message for this parameter is shown to the end-user. [Page execution step 5.]

You can also undo the last utterance and try something else to test different page transitions.

[Undo utterance.]

Create a page

To create a page:

Page data

To access a page's data:

The following data is associated with pages:

• Display name: A human-readable name for your page.
• Entry fulfillment (also known as Entry dialogue): This is the fulfillment to call when the page initially becomes active.
• Parameters: These are the parameter values in a page form that capture structured input from the end-user.
• Routes: These state handlers may be called when the page is active. For details, see Page-level handler routes
• Route groups: The routes within these groups may be called when the page is active. For details, see Route groups
• Event handlers: These event handlers may be called when the page is active. For details, see Page-level event handlers

Page settings

The following settings are available for pages:

• Advanced speech settings: These advanced speech settings can optionally override the same flow speech settings and agent speech settings.

• Speech adaptation settings: Page level speech adaptation settings can optionally override the same flow speech adaptation settings. More detailed instructions in manual speech adaptation.

To access page settings:

Delete a page

To delete a page: