Google Dialogflow CX Flow

This page shows how to write Terraform for Dialogflow CX Flow and write them securely.

google_dialogflow_cx_flow (Terraform)

The Flow in Dialogflow CX can be configured in Terraform with the resource name google_dialogflow_cx_flow. The following sections describe how to use the resource and its parameters.

Example Usage from GitHub

An example could not be found in GitHub.

Review your Terraform file for Google best practices

Shisho Cloud, our free checker to make sure your Terraform configuration follows best practices, is available (beta).

Parameters

The following arguments are supported:

  • display_name - (Required) The human-readable name of the flow.

  • description - (Optional) The description of the flow. The maximum length is 500 characters. If exceeded, the request is rejected.

  • transition_routes - (Optional) A flow's transition routes serve two purposes: They are responsible for matching the user's first utterances in the flow. They are inherited by every page's [transition routes][page.transition_routes] and can support use cases such as the user saying "help" or "can I talk to a human?", which can be handled in a common way regardless of the current page. Transition routes defined in the page have higher priority than those defined in the flow.

    TransitionRoutes are evalauted in the following order: TransitionRoutes with intent specified. TransitionRoutes with only condition specified. TransitionRoutes with intent specified are inherited by pages in the flow. Structure is documented below.

  • event_handlers - (Optional) A flow's event handlers serve two purposes: They are responsible for handling events (e.g. no match, webhook errors) in the flow. They are inherited by every page's [event handlers][page.event_handlers], which can be used to handle common events regardless of the current page. Event handlers defined in the page have higher priority than those defined in the flow. Unlike transitionRoutes, these handlers are evaluated on a first-match basis. The first one that matches the event get executed, with the rest being ignored. Structure is documented below.

  • transition_route_groups - (Optional) A flow's transition route group serve two purposes: They are responsible for matching the user's first utterances in the flow. They are inherited by every page's [transition route groups][page.transition_route_groups]. Transition route groups defined in the page have higher priority than those defined in the flow. Format:projects/<Project ID>/locations/<Location ID>/agents/<Agent ID>/flows/<Flow ID>/transitionRouteGroups/<TransitionRouteGroup ID>.

  • nlu_settings - (Optional) NLU related settings of the flow. Structure is documented below.

  • parent - (Optional) The agent to create a flow for. Format: projects/<Project ID>/locations/<Location ID>/agents/<Agent ID>.

  • language_code - (Optional) The language of the following fields in flow: Flow.event_handlers.trigger_fulfillment.messages Flow.event_handlers.trigger_fulfillment.conditional_cases Flow.transition_routes.trigger_fulfillment.messages Flow.transition_routes.trigger_fulfillment.conditional_cases If not specified, the agent's default language is used. Many languages are supported. Note: languages must be enabled in the agent before they can be used.

The transition_routes block supports:

  • name - The unique identifier of this transition route.

  • intent - (Optional) The unique identifier of an Intent. Format: projects/<Project ID>/locations/<Location ID>/agents/<Agent ID>/intents/<Intent ID>. Indicates that the transition can only happen when the given intent is matched. At least one of intent or condition must be specified. When both intent and condition are specified, the transition can only happen when both are fulfilled.

  • condition - (Optional) The condition to evaluate against form parameters or session parameters. At least one of intent or condition must be specified. When both intent and condition are specified, the transition can only happen when both are fulfilled.

  • trigger_fulfillment - (Optional) The fulfillment to call when the condition is satisfied. At least one of triggerFulfillment and target must be specified. When both are defined, triggerFulfillment is executed first. Structure is documented below.

  • target_page - (Optional) The target page to transition to. Format: projects/<Project ID>/locations/<Location ID>/agents/<Agent ID>/flows/<Flow ID>/pages/<Page ID>.

  • target_flow - (Optional) The target flow to transition to. Format: projects/<Project ID>/locations/<Location ID>/agents/<Agent ID>/flows/<Flow ID>.

The trigger_fulfillment block supports:

  • messages - (Optional) The list of rich message responses to present to the user. Structure is documented below.

  • webhook - (Optional) The webhook to call. Format: projects/<Project ID>/locations/<Location ID>/agents/<Agent ID>/webhooks/<Webhook ID>.

  • return_partial_responses - (Optional) Whether Dialogflow should return currently queued fulfillment response messages in streaming APIs. If a webhook is specified, it happens before Dialogflow invokes webhook. Warning: 1) This flag only affects streaming API. Responses are still queued and returned once in non-streaming API. 2) The flag can be enabled in any fulfillment but only the first 3 partial responses will be returned. You may only want to apply it to fulfillments that have slow webhooks.

  • tag - (Optional) The tag used by the webhook to identify which fulfillment is being called. This field is required if webhook is specified.

The messages block supports:

The text block supports:

  • text - (Optional) A collection of text responses.

  • allow_playback_interruption - Whether the playback of this message can be interrupted by the end user's speech and the client can then starts the next Dialogflow request.

The event_handlers block supports:

  • name - The unique identifier of this event handler.

  • event - (Optional) The name of the event to handle.

  • trigger_fulfillment - (Optional) The fulfillment to call when the event occurs. Handling webhook errors with a fulfillment enabled with webhook could cause infinite loop. It is invalid to specify such fulfillment for a handler handling webhooks. Structure is documented below.

  • target_page - (Optional) The target page to transition to. Format: projects/<Project ID>/locations/<Location ID>/agents/<Agent ID>/flows/<Flow ID>/pages/<Page ID>.

  • target_flow - (Optional) The target flow to transition to. Format: projects/<Project ID>/locations/<Location ID>/agents/<Agent ID>/flows/<Flow ID>.

The trigger_fulfillment block supports:

  • messages - (Optional) The list of rich message responses to present to the user. Structure is documented below.

  • webhook - (Optional) The webhook to call. Format: projects/<Project ID>/locations/<Location ID>/agents/<Agent ID>/webhooks/<Webhook ID>.

  • return_partial_responses - (Optional) Whether Dialogflow should return currently queued fulfillment response messages in streaming APIs. If a webhook is specified, it happens before Dialogflow invokes webhook. Warning: 1) This flag only affects streaming API. Responses are still queued and returned once in non-streaming API. 2) The flag can be enabled in any fulfillment but only the first 3 partial responses will be returned. You may only want to apply it to fulfillments that have slow webhooks.

  • tag - (Optional) The tag used by the webhook to identify which fulfillment is being called. This field is required if webhook is specified.

The messages block supports:

The text block supports:

  • text - (Optional) A collection of text responses.

  • allow_playback_interruption - Whether the playback of this message can be interrupted by the end user's speech and the client can then starts the next Dialogflow request.

The nlu_settings block supports:

  • model_type - (Optional) Indicates the type of NLU model.

    • MODEL_TYPE_STANDARD: Use standard NLU model.
    • MODEL_TYPE_ADVANCED: Use advanced NLU model. Possible values are MODEL_TYPE_STANDARD and MODEL_TYPE_ADVANCED.
  • classification_threshold - (Optional) To filter out false positive results and still get variety in matched natural language inputs for your agent, you can tune the machine learning classification threshold. If the returned score value is less than the threshold value, then a no-match event will be triggered. The score values range from 0.0 (completely uncertain) to 1.0 (completely certain). If set to 0.0, the default of 0.3 is used.

  • model_training_mode - (Optional) Indicates NLU model training mode.

    • MODEL_TRAINING_MODE_AUTOMATIC: NLU model training is automatically triggered when a flow gets modified. User can also manually trigger model training in this mode.
    • MODEL_TRAINING_MODE_MANUAL: User needs to manually trigger NLU model training. Best for large flows whose models take long time to train. Possible values are MODEL_TRAINING_MODE_AUTOMATIC and MODEL_TRAINING_MODE_MANUAL.

In addition to the arguments listed above, the following computed attributes are exported:

  • id - an identifier for the resource with format [[parent]]/flows/[[name]]

  • name - The unique identifier of the flow. Format: projects/<Project ID>/locations/<Location ID>/agents/<Agent ID>/flows/<Flow ID>.

Explanation in Terraform Registry

Flows represents the conversation flows when you build your chatbot agent. To get more information about Flow, see:

Frequently asked questions

What is Google Dialogflow CX Flow?

Google Dialogflow CX Flow is a resource for Dialogflow CX of Google Cloud Platform. Settings can be wrote in Terraform.

security-icon

Automate config file reviews on your commits

Fix issues in your infrastructure as code with auto-generated patches.