Publish your Actions

Publishing is the general process that makes your Actions available to users. This page provides an overview of the process of publishing your Actions.

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, because you want users to trigger your Action. 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 userdata, 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 that your Action is rejected.
  • Review your invocation and display names: Make sure your invocation name is consistent with the display name that will appear on your Assistant directory page. Ensure both names are specific enough that users can easily call 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 the name users use to explicitly invoke your Action. This name is also used in the Assistant directory.

To set your display name, follow these steps:

  1. Navigate to Develop > Invocation.
  2. Enter the display name for your Action.
  3. Click the Play play_circle_filled icon to hear how the name is pronounced.

Screenshot of the display name option in the Actions console

Changing your display name

You can change the display name for your Action at any time, however your Action will need to go through a 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.

Screenshot of the location targeting options
Figure 5. Specifying regions an Action supports.

Read more about localized publishing.

Optional: Specify surface capabilities

Your Action can appear on a variety of surfaces that the Assistant supports, such as phones (Android and iOS) and smart displays.

Surface capabilities let you 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.

Screenshot of the surface capabilities options
Figure 6. Specify the surface types that your Action triggers on.

Read more about surface capabilities.

Test with the simulator

Before publishing your Action, you should use the simulator to test the user experience 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're signing your webhook requests (Dialogflow or Actions SDK) and verifying 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 in figuring out how to improve the user experience.

To test your current Actions project draft, click the Test tab. This will make the current version of your draft available in the simulator in the console as well as on your own Assistant-enabled devices.

Screenshot of the Actions console simulator
Figure 7. Testing with the Actions simulator.

Read more about the Actions simulator.

Publish 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 release to users.

  • Alpha: This release channel is best used for quick testing iterations. Your Action is distributed to a small of users you define, without going through a full Google review.
  • Beta: This release channel is 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 anytime.
  • Production: This submits your Action for full Google review. Once it has been approved, your Action will be available to Assistant users.

Read more about releases.

Publish options are found under Deploy > Release.

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, you can publish an approved version at any point from the console without going through an additional review.

Google regularly sends requests to the endpoint of your MAIN intent, 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 Published.

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 needs to be resubmitted and goes through the 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 the 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 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 unpublished and the latest version of your Action will be available to 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.

Screenshot of the Actions overview page showing previously released versions
Figure 8. Selecting an Actions project version to view.

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 published, you can select Undeploy from production to take your Action down.
  • When a previous version is unpublished, you can select Deploy to production to revert to that version.