Implement built-in intents for App Actions

Built-in intents allow your app to express its fulfillment capabilities to Google. By registering intents in your actions.xml file and mapping intent parameters to the fulfillment, you make it possible for Google Assistant to deep link into your app in response to user queries.

Built-in intents are grouped according to app categories. Each category represents a set of common tasks that users frequently want to perform on their apps. The full list of available built-in intents, their parameters, and example queries usable for testing is in the built-in intent reference.

Many built-in intents include additional deployment requirements and recommendations. These requirements and recommendations help us ensure that your app delivers the best possible experience to your users.

Figure 1. Invoking START_EXERCISE.

Figure 2. Deep linking into the app.

Figure 3. Launching a Slice in Assistant.

Handling intent parameters

For App Actions, you handle built-in intent parameters in your actions.xml file. Handling an intent parameter requires that you map the intent parameter to a URL template variable in your <fulfillment> tag, then use its value in your app. Unless otherwise specified, it's optional to handle supported parameters for an intent.

Intent parameters that must be handled for a built-in intent are highly recommended when your app supports functionality related to those parameters. Also, intent parameters that must be handled do not need to be handled in all functionality that uses that intent.

For example, the actions.intent.GET_EXERCISE_OBSERVATION intent recommends your app to handle the exerciseObservation.aboutExercise.name parameter. You can still implement the same intent in your app with no parameters, as long as at least one other fulfillment handles exerciseObservation.aboutExercise.name for this intent. You might do this if you wanted to handle user queries without specific exercises, like "Ask ExampleApp what exercises I did yesterday".

Key Term:

• Disambiguation: In certain cases, such as food ordering, you may need to disambiguate items in your search results. This means that if you can't resolve the data passed in to a single item, present multiple choices to the user, let them select one, then proceed.

Google Assistant does its best to provide the most relevant information to the user when returning parameter values to your app. For example, user queries for ordering pizza from ExampleRestaurant's mobile app don't always include a location. To better serve the user, Assistant may choose to provide latitude and longitude values of the nearest ExampleRestaurant to that app.

As an additional requirement, your app should not directly perform an action that modifies a user's real-world state (for example, transferring money, placing an order, or sending a message) without first confirming with the user.

Note: App Actions, like all Actions that support built-in intents, trigger on a number of factors, including quality and relevancy to the user's request. Based on those factors, Google may exercise discretion in surfacing your Action in response to user requests.

Language and locale support

The locales supported for development and testing by each App Action built-in intent are listed in the built-in intent reference. Some built-in intents have different locale support for developer testing and for user triggering from Assistant.