Publish your Actions

Publishing is the general process that makes your Actions available to users. When you publish an Action, you perform two main tasks:

  • Prepare your project: Specify information that users see about your Action in the Assistant directory. You can also configure other options, like setting which device types and regions your Action will be available in.
  • Deploy your project: Submit your Actions project to Google for review. When approved, an email notification is sent and Google serves your Action to users (usually within two to three hours).

This page provides an overview of the process you should follow as you prepare to publish your Actions.

Prepare your project

Before you can submit your draft project for approval and publishing, you must provide metadata about your project in the console. The following sections describe the information that you need to provide.

Add directory information

Users discover your Action by searching or browsing the Assistant directory. Providing complete information for your Action gives users an idea of what your Action does and what they can expect from the content.

To add the information you want to present to users for your Actions, follow these steps:

  1. In the console, select your project and go to Deploy > Directory information.
  2. Enter both a short description that describes its function in one line, and a more complete description for your Action.
  3. Enter sample invocations or phrases that users can say to invoke your Action.

  4. Provide banner and logo images for your project. Image size requirements are 1920 x 1080 pixels for the banner image and 192 x 192 pixels for the logo image.

  5. Enter links to your privacy policy and terms of service. These links are publicly available to users.

  6. Pick the category that is most appropriate for your Action.

  7. If your Action targets children as its primary audience or as one of its primary audiences, toggle the For Families option to Yes to join the Actions for Families program.

  8. If your Actions features any alcohol or tobacco-related content, toggle the Alcohol and Tobacco option.

  9. Optionally, enter testing instructions for your Actions. These instructions are only visible to the review team; users will not see them.

Figure 1. The directory information page in the Actions console.

Add details for other languages

If your Action uses multiple languages and locales, information can be specified for each of your projects.

By default, your browser language is pre-selected in the language drop-down when you create a new project. To add additional languages:

  1. Click the options more_vert icon < Project settings.
  2. Click the Languages tab.
  3. Click the check box next to each language you want your Action to support.
  4. Click Save.
Figure 2. Choosing languages for an Actions project.

After selecting additional languages, metadata for each language in your project is added by following these steps:

  1. Click Overview in the top menu.
  2. Click on Deploy < Directory information.
  3. Select a language from the picker in the upper-left corner.

    Figure 3. Adding directory information for a language.
  4. Add details as described in the Directory information section.

  5. Click Save.

Export metadata for translation

If you need to translate your project's metadata for different locales without granting translators access to the console, you can export your project's metadata as resource strings that can be externally translated and imported back into your project.

To do this, follow these steps:

  1. Click Overview in the top menu.
  2. Click Deploy > Directory information.
  3. Click ⋮ to the right of the language selector and Export for translation to download a .zip archive.

    Figure 4. Exporting directory information.
  4. The .zip archive contains .xlf files for each locale. Each file includes a <source> and <target> translation for each field in the description for this Action:

      <trans-unit id="tu3" resname="shortDescription">
      <source xml:lang="en">short description</source>
      <target xml:lang="it">short description</target>
      <note>The default short description for the Action (if there is not a translation available). This is limited to 80 characters.</note>
      </trans-unit>
    
  5. Replace the <target> strings with translated strings for the file's locale:

      <trans-unit id="tu3" resname="shortDescription">
      <source xml:lang="en">short description</source>
      <target xml:lang="it">Breve descrizione</target>
      <note>The default short description for the Action (if there is not a translation available). This is limited to 80 characters.</note>
      </trans-unit>
    
  6. Re-zip the folder containing all of the now-translated .xlf files.

  7. Navigate back to the Directory information page in the console, click ⋮ near the top and Import translations to upload your archive.

Optional: Specify location targeting

By default, your Actions are 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 is used to control region availability for your Action.

Figure 5. Specifying regions an Action supports.

To learn more, see see the localized publishing guide.

Optional: Specify surface capabilities

Your Actions can appear on a variety of surfaces that the Assistant supports, such as phones (Android and iOS) and voice-activated speakers.

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.

Figure 6. Specify the surface types that your Action triggers on.

To learn more, see the surface capabilities guide.

Test with the simulator

Before publishing your Action, you should use the simulator to test 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.

Figure 7. Testing with the Actions simulator.

To learn more, see the Actions simulator guide.

Publish your project

Once you've prepared and tested your project draft and are happy with the results, you can deploy it to users. To do this, navigate to Deploy > Release and click the Submit For Production button.

This submits the current draft of your project for review. Our review team will test your Action against our policies and if it is approved, it will be available to users.

As updates occur, you'll get emails and you can always track the status by returning to the Overview section of the console.

Deployment status

The following table describes the different deployment statuses once you have submitted your project and any next steps you 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 An unapproved status means that your deployment was denied. You should receive an email explaining why your deployment was denied. You can also click Why? next to the Unapproved status in the console to see the rationale for the denial.
Published An approved deployment that is active and being served to users. Note that you can unpublish a published version at any point from the console.
Unpublished An approved deployment that is not currently active and is not being served to users. Note that you can publish an unpublished version at any point from the console without going through review (since it has already been approved).
Published and Unpublishing Publishing and unpublishing takes some time to take effect. These intermediate states reflect that your Action is either transitioning from unpublished to published, or vice versa.
Unhealthy

Google will regularly send a request to the endpoint of your MAIN intent, and check that we get an appropriate response. If we detect that your endpoint has gone down or is unresponsive, we will temporarily stop serving your Action to users.

In this case, you will receive an email informing you that your endpoint is unhealthy, and we will also show an Unhealthy status. As soon as we detect that your endpoint is responsive again, we will resume serving your Action to users. You will receive an email if 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 your the information about your Action in the console (for example, the Action's name and icon); these changes will result in a new version of your project. You must resubmit each version through the review process before your updated Action is released to the public.

Update an Action

When you have made your updates in your project draft, navigate to Deploy > Release and click Submit For Production. This creates a new project version which goes through the same review process as before. 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 the Overview page and click the version in the table you want information about.

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 to unpublish it.
  • When a previous version is unpublished, you can select Rollback to this version to revert to that version.

Now that your Action is available to users, continue on to the Analytics and Health section to see how it's performing.

When to resubmit your project

If your project is already published, subsequent changes you make may not be reflected immediately.

In order for your changes to go live, you will need to resubmit your project through the review process, if any of these situations apply:

  • You made a change in the console to modify the project's description, icon, or other metadata.
  • You are using the Actions SDK and made changes in your Action package.
  • You are using Dialogflow and made changes to your Dialogflow agent. This does not apply if you only made changes to the fulfillment code in Dialogflow's inline editor.

However, you do not need to resubmit your project for these scenarios:

  • You only made changes to your code in an externally-hosted webhook or in Dialogflow's inline editor.
  • You are using Templates, and you updated your template data via uploading content to Google sheets.

Building a good Assistant directory listing

Your Actions project is featured on its own page, so it's important that you promote and highlight your capabilities and provide everything users need to know about your Action. A good directory page should at least include the following:

  • An icon and splash image - These should reflect your brand appropriately and differentiate your Action from others
  • Action display name - Associates a name and brand with your Action
  • Description - A brief rundown of what the Action can do and its features
  • Sample invocations - This teaches users how to invoke your Actions after they discover them

Categorization

Categorization helps users better understand your Action's capabilities and create new avenues for your Action to be discovered. Actions are grouped by vertical categories (e.g. food & drink) that you can select through the Directory information section of the Actions Console.

Actions are also grouped by task-based subcategories, which are based on the actions you've defined for your Action (e.g. find food recipes, order food, get nutrition facts). If your Action accomplishes multiple different tasks for users, it may be listed under more than one task category. In this case, you may also want to consider categorizing it under more than one vertical category.

To make sure your Action is properly represented, make sure that your description and sample invocation accurately describe all of your Action's use cases. If you have any issues with your Action's page or feel your Action has been miscategorized, contact support.

Modifying your directory page

All actions will be automatically available in our directory. You are able to modify the page(s) representing your action, however, by following the instructions below.

  1. Go to your Actions on Google project by signing into the Actions Console.

    • If you don't have a project yet, you'll need to make sure you claim your page first, which you can do by clicking a link at the bottom of your page in the directory.
  2. Navigate to Deploy > Directory information

  3. You can edit and change the following fields that show to users:

    • Short description
      • A short, one line description of your Action
    • Full description
      • A complete description of your Action
    • Large banner image
      • A large banner image which will be shown at the top of your Action's page in the directory
    • Small square logo
      • A small logo which will be shown in the directory, as well as other places where your Action is referenced
    • Category
      • The category that best describes your Action (e.g. "Food & Drink"). This will help users discover your Action.
    • Testing instructions
      • Provide any additional information needed to test your Action. If your Action requires account linking or login information, you must provide a username and password for a test account. Please make sure that any provided accounts are not real user accounts. This information will only be used by the review team, and will not be visible to users.

Submit your changes to the review team by selecting Submit for review. The team will review your changes to your directory page and approve shortly if there are no required corrections.