Before you release your Action to users, you should test it thoroughly, specify the target surfaces, locations, and devices, and verify that it complies with Google's policies for Actions. This page provides an overview of the tasks you should perform as you prepare to submit your Action for review, to obtain approval to release it to Beta or Production channels.
Check for policy violations
Verify that your Action follows the policies for Actions on Google. In general, follow these guidelines for your content:
- Be specific: Users must be able to invoke your Action specifically. Don't be too broad or general when choosing a display name or pronunciation. For example, use "Talk to WeatherApp to check the weather for [city]" instead of "Check the weather for [city]" as an Action phrase. Follow the guidelines for providing good Action phrases.
- Avoid prohibited content: Unless it serves a scientific, artistic, documentary or educational purpose, Actions with explicitly sexual, violent, illegal, or hateful content violate the policies for Actions on Google. Actions that promote bullying or harassment will also be rejected or taken down.
- Respect copyrights and intellectual property: Make sure you have adequate rights to use the content offered by your Action.
- Be honest: Don't mislead or deceive users with false claims.
- Protect users' privacy and security: Be transparent in how you handle user data, transmit user data securely, and provide a privacy policy.
- Don't listen to users unprompted: Users need to understand when your Action is waiting for their input. Leaving the mic open without prompting the user is a common mistake that is outlined in our policies. Make sure your Action notifies the user when it's waiting for a command to reduce the risk of your Action being rejected.
- Review your invocation and display names: Make sure your invocation name is consistent with the display name, which appears on your Assistant directory page. Ensure both names are specific enough that users can easily invoke your Action. Your invocation and display names must also follow the policies for Actions on Google.
Check the full list of policies and make sure you comply with them to expedite review and approval of your Action.
Set display name
The display name defines how users explicitly invoke your Action. This name is also used in the Assistant directory.
To set your display name, follow these steps:
- Navigate to Develop > Invocation > Settings.
- Enter the display name for your Action.
- Click the Play play_circle_filled icon to hear how the name is pronounced.
Change your display name
You can change the display name for your Action at any time; however, your Action will go through another full review process before users can invoke your Action using the new name.
Optional: Specify location targeting
By default, your Action is available in all regions as long as the user's device locale is set to an "English" variant (for example, American English or British English).
The Location targeting setting controls regional availability for your Action.
Read more about localized publishing.
Optional: Specify surface capabilities
Your Action can appear on a variety of surfaces that Assistant supports, such as phones (Android and iOS) and smart displays.
Surface capabilities allow you to control whether or not users can invoke your Action based on the surface they use. If users try to invoke your Action on an unsupported surface, they receive an error message telling them their device is unsupported.
Read more about surface capabilities.
Optional: Specify Interactive Canvas options
If your Action uses Interactive Canvas, you need to enable and set a couple options under Develop > Interactive Canvas in the left navigation.
- Enable the option for using Interactive Canvas with your Action.
- Enter the URL for the web app that hosts the visuals for your Action.
Test with the simulator
Before releasing your Action, use the simulator to test the user experience of your Action and make sure everything works.
Check for the following common errors and violations:
- Webhook transport must be secure: Verify that you use HTTPS (TLS) encryption on the transport for your webhooks.
- Verify webhook requests: Make sure that you sign your webhook requests using the Actions SDK and verify them in your webhook.
- Test your Action name: Make sure that the Action name you've set consistently triggers your Action. Use a hardware device or the web simulator and speak your invocation name repeatedly, in different real-world scenarios (i.e., with noise in the background, or at different distances from the device). If possible, ask people of different genders or with different accents to invoke your Action. If your invocation name is not consistently recognized, you may want to change it.
- Test on physical devices: Although the web simulator is great for testing your Action quickly while developing, you should always test invocation and dialogs on real devices. This is the best way to understand how your Action functions in real life and helps you improve the user experience.
To test your current Actions project draft, go to Test in the main navigation. This ensures the current version of your Action is used across the simulator, the console, and Assistant-enabled devices.
Read more about the Actions simulator.
Release your project
Once you've tested your project draft and are happy with the results, you can deploy it to Alpha or Beta channels for additional testing. Alternatively, you can submit it for review and to release to Assistant users.
In the Deploy > Release section of the console, you'll find the following options for releases:
- Alpha: Best used for quick testing iterations. Your Action is distributed to a small set of users you define without going through a full Google review.
- Beta: Best used for distributing your Action to a limited set of users after a full Google review. Since the Action has passed a full review, you can elect to make it public at any time.
- Production: Submits your Action for full Google review. Once it has been approved, your Action will be available to Assistant users.
Read more about releases.
Deployment status
The following table describes the different deployment statuses of a project and additional steps you may need to take:
| Deployment status | Description |
|---|---|
| Under Review |
When you submit a new deployment, it goes through an approval process. Reviewers test your Action and verify that you haven't violated any policies. You will receive an email once a review has been completed telling you whether your deployment was approved or not. |
| Denied | A denied status means that your deployment was not approved. You should receive an email explaining why your deployment was denied. You can also click Why? next to the Denied status in the console to see the rationale for the denial. |
| Deployed | An approved Action that is active and being served to users. You can "take down" a deployed version at any point from the console. |
| Approved | An Action that has passed review and is not currently being served to users. When an Action has already successfully gone through review, it can be released at any point from the console, without going through an additional review. |
| Unhealthy | Google regularly sends requests to the endpoint of your Action and checks that we get an appropriate response. If we detect that your endpoint is down or unresponsive, we temporarily stop serving your Action to users. In this case, you'll receive an email informing you that your endpoint is unhealthy, and your Action has moved to an Unhealthy status. As soon as we detect that your endpoint is responsive again, we will resume serving your Action to users. You'll receive an email when this happens, and your deployment’s status should return to Deployed. |
| Taken down | Google may take down your Action if we detect a policy violation after deployment. You will receive an email if this happens, and you will also see a banner in the developer console informing you that your Action has been taken down. You can click Why? to see the rationale, and to see your options for either fixing the policy violation or appealing the decision. |
Versioning your project
Over time, you may want to update information about your Action. Some changes to an Action result in a new version of your project. Each new version must be resubmitted and go through the full review process before the updated Action is released and served to the public.
Making any of the following changes requires you to resubmit an Action for review:
- A change is made in the console to modify the project's description, icon, or other metadata.
- Using Actions Builder or the Actions SDK, you made changes to your Actions project.
- Using the legacy Actions SDK, you made changes to your Action package.
- Using Dialogflow, you made changes to your Dialogflow agent.
You do not need to resubmit your project for the following scenarios:
- You only made changes to your code in an externally-hosted webhook, the inline webhook editor in Actions Builder, or in Dialogflow's inline editor.
- You use Templates, and you updated your template data via uploading content to Google sheets.
To submit your updated Action for review, go to Deploy > Release and click Create a release. If approved, the previous version will be undeployed and the latest version of your Action will be available to Assistant users.
Track and modify versions
To track and get information about your versions, go to Deploy > Release and click the version you want information about.
The table shows the last modified date and the current status of the version. You can make specific changes to the status, depending on the version's current status.
- If a version is under review, you can select to withdraw the version from review.
- If a version is deployed, you can select Undeploy from production to take your Action down.
- When a previous version is undeployed, you can select Deploy to production to revert to that version.