Dialogflow to Actions Builder migration tool

Actions Builder is the best way to build for Google Assistant, as it helps you build Conversational Actions in a simplified and streamlined manner. Actions Builder is a web based IDE that is integrated into the Actions console, and provides the following features:

• Visual workflow and state-based way to control your Action's conversations.
• Faster prototyping and reduced latency.
• Single interface for building, analyzing, and debugging your Conversational Actions.

If you have a Conversational Action you built with Dialogflow, you can choose migrate your project to Actions Builder within the Actions console.

Note: Migrating your Dialogflow project to Actions Builder is optional.

Reasons to migrate

While there's no requirement for migrating your Dialogflow agent, and your Action will continue to function for Google Assistant devices, there are benefits to using Actions Builder and the Actions SDK.

• Improved tooling with the Actions SDK and CLI

  • The Actions SDK and CLI enable you to build complex projects and easily collaborate with your teams. Conversation designers can first build the conversation flow in Actions Builder. Developers can then download the project into a file-based structure and continue building functionality using their favorite development tools and version control systems. By pushing the project back to Actions Builder, other teammates can continue to build, test, and deploy the Action.

• Better integration with conversation design best practices

  • Customization of fallback intents within each scene allows you to provide no-input and no-match responses at any point in the conversation.
  • Easy collaboration between designers and developers due to the graphical, state-based method of building a conversational experience.

• Easier localization

  • All localizable content for intents, scenes, and types (like training phrases, prompts, and type synonyms) can be edited on one page.

  

Conversational implementation improvements

Actions Builder brings a lot of improvements to Actions console and simplifies the development processes. This section describes how Actions Builder streamlines and simplifies the process of developing your Action.

Intent reusability

In Dialogflow, webhook logic is tied to intents, which means intents cannot be reused with other webhooks. If you want to use the same training phrases, but have different webhook logic, you have to create additional intents that refer to different handler names for each webhook logic case.

In Actions Builder, an intent includes training phrases and entities, but the webhook is independent. This approach means you can use different webhook handlers for the same intent, giving you more flexibility.

Improved visualization of conversation flow

In Dialogflow, contexts indicate what intents are more likely to match, at a certain point in the conversation.

Instead of contexts, Actions Builder uses scenes to handle which intents are accessible in different parts of the conversation

When a user enters a scene, transitions define conversational paths the user can take. Transitions can be based on conditional logic, as well as custom or system intent matching.

Builder's UI makes it easy to understand how transitions connect scenes. In Figure 1, the scene guess_game transitions to the suggested_new_game scene (1). You can also see the two accessible intents within the scene: generic_no and generic_yes. Depending on which intent gets matched, the suggested_new_game scene transitions to either the show_menu or routing_game scene (2).

Figure 1. Graphical view of a scene, with the scene's transition (1) and intent handling (2).

Customizable prompts based on scenarios

In Dialogflow, you can send a simple response in the webhook or define a static response in the Dialogflow console.

Actions Builder introduces the concept of a prompt queue. You can define prompts in multiple sections of a scene, as well as in your webhook. All prompts are added to the prompt queue, merged to one response, and delivered to the user. This approach allows you to piece together responses based on what users have said or done, and not just based on the intent they matched.

For example, if prompts are defined in a scene and the webhook, the webhook prompt is added to the prompt queue first, and the scene prompt is added second.

The following list outlines where you can define prompts in Actions Builder, and the order they're added to the prompt queue:

1. On enter
2. Conditions
3. Slot filling
4. Scenes

Note: Webhooks calls can be enabled everywhere prompts can be defined within scenes. In all cases, when both scene prompts and webhook prompts are provided, the webhook prompt is added to the queue before the scene prompt.

Built-in conversation design best practices

When a Dialogflow project is set up, a global fallback intent is automatically generated, just like the default welcome intent. The default fallback intent gets matched when a user says something that can't be matched to existing intents or when there is no user input.

In order to handle errors gracefully, follow up intents need to be added to the fallback intent for each conversational turn.

In Actions Builder, two separate global intents are automatically included in new projects: NO_MATCH and NO_INPUT.

When the Assistant NLU matches the NO_MATCH or NO_INPUT system intent, the respective default or customized prompt is sent to the user. Once NO_MATCH or NO_INPUT is matched three times, the respective final message is sent to the user and the Assistant ends the conversation with your Action.

You can add three NO_MATCH and NO_INPUT handlers to each scene. This feature allows for customizable prompts for specific error handling, instead of a general fallback caused by no match or no input from the user.

Figure 2. Three NO_MATCH intent handlers assigned to a single scene.