Google Actions Re-certification requirements - dialogflow-es

Do we need to re-certify a deployed skill if we edit Entities (eg: add synonyms) to Dialogflow or edit Types in case of using Actions Builder?
Essentially is there an "Update Live Skill" option similar to Alexa Skills Kit, where any published skill can be updated immediately when changes are limited to sample utterances within an intent or slot/entity values.

Yes updates to the conversational model will require a redeploy, which will require a review if you go to the beta or production channels. Alpha releases do not require a review.
The releases documentation may provide more information.

Related

Google Assistant - existing dialogflow intents & new actions cooperation

I have a technical question about the Google Assistant - unfortunately, I couldn't find a clear answer anywhere.
At the moment our company have:
the conversational chatbot built on Dialogflow, which is constantly developed by our employees
Google Actions agent. Our developers managed to construct the connection of the Google account and our client's account on our platform using OAuth 2.0 and created the first actions that, by the exchange of tokens, allow the return of certain information from our platform to the Google Assistant and vice versa - providing certain information in the Google Assistant that are sent and saved in the customer's account on our platform.
We would like both actions on actions.google.com (2) and conversations on Dialogflow (1) to cooperate with each other in the Google Assistant. One team is working on the chatbot, and the other on advanced actions, and we would like it to stay that way.
My question is - is the absolute only way to finally publish it on the google assistant is to migrate the chatbot from Dialogflow to Actions Builder and stop using Dialogflow?
Or maybe there is a simpler solution where both these environments (of course woring on one profile / agent) cooperate with each other and it will be possible to continue working on dialogflow?
We understand the advantages of Action Builder, but Dialogflow is just good enough for our needs.
There are a few angles to how you can approach this, depending on your exact needs and limitations you may accept, but the general answer is "yes, you can do both at the same time".
First, Dialogflow ES continues to support the Actions on Google Integration. Just as your Dialogflow agent integrates with other platforms, it should still be able to integrate with Actions.
There are some caveats (and some upsides!) with this, however:
You'll be using the Actions on Google v2 platform, rather than the v3 that comes with the Action Builder (and newer SDK). If the features you need are supported on v2, then you're fine. (Account Linking is supported in v2.) But if you need some of the features in v3, then you will run into problems.
You can't have used the Action Builder on the same Cloud project, and you should start the integration from the Dialogflow side. (But once you do - you'll be able to use the Actions Console to do things such as submit it for review, etc.)
Make sure you do not "upgrade" from Dialogflow to Actions Builder. This severs the two, so you won't be able to update the Action from Dialogflow.
Another approach is that you can use Action Builder, but have it forward all (or nearly all) of the requests to Dialogflow. Under this scheme, you would have an Action Builder project that has as little as one Scene with an Intent that captures all input, sends that to a webhook you control, which sends it to your Dialogflow agent via the Dialogflow API, gets the response from your Dialogflow agent, and forwards that response through Action Builder.
This is a little more complicated, but may offer some benefits if you want to take advantage of more advanced Action concepts that may not be available using v2.

Deleting projects from Dialogflow CX

I can't figure out how to delete dialogflow cx projects. I was messing around with it, and maxed out the number of projects, and now regular dialogflow is broken. There are no agents in any of the projects, but I can't delete them.
Dialogflow CX project refers to a GCP project as stated in the documentation. In order to have multiple agents it is often more useful to create different agents within the same GCP project, as the GCP Console of the project is used to manage GCP-specific Dialogflow CX settings, as explained here.
In the following link you will find the troubleshooting steps to follow if you are having troubles deleting a GCP project.
Considering that your issue seems to have affected the Dialogflow Essentials edition you may need to open a ticket with Support to provide further insights on that matter. However, Bear in mind that Dialogflow CX product is still on its Beta release and the Support that may receive might be limited or it may change in the future.
In this link you will find a summary on how to get support for Dialogflow. In case you do not have a paid support plan with Google Cloud Platform it's advised to file the Dialogflow support form.
You can delete the prj in https://console.cloud.google.com/iam-admin/settings
screen shot
After you shutdown the prj, Google will deleted it after 30 days.

Can I release Google Assistant Private App

I'm developing a Google Assistant Action using Dialogflow.
When the development is completed, I want to release this Action to Assistant.
But this Action is purely for personal use, so I worry that the release is rejected.
Has anyone released a private Action?
I don't want Alpha or Beta version app, because these versions are included 'Test Version' phrases when the version load
If the Action is completely private (ie - just for you) then leaving it in an Alpha channel is most appropriate.
If the audience is broader, but still very limited, and you don't want to deal with the "test" phrase, and you are willing to have it reviewed, then you can limit access to it by using the Google Sign In for Assistant, which will give you a user ID which you can check against a whitelist.

How To construct Intents in Dialogflow

I'm creating a chatbot to identify questions about store and products and answer accordingly with Dialogflow. But when constructing intents I came across this problem. The approaches I think I can construct as follows.
1st Approach
Create multiple intents
GetPrice, GetColor, GetAvailability, GetType, GetStoreName, GetStoreContact
The difficulty that I found in this approach is I have to create dozens of intents for all product types and for all types of questions about store
The advantage is that I can train for the intents seperately.
2nd Approach
Create 2 intents
ProductQuestions, StoreQuestions
The training has to be done for all the 1st approach question types in those 2
What approach I should take? In future this will be more scalable.
Most logic for conversation design can be based on your personal preferences. If you're looking for best practices, check out Google's documentation here:
https://developers.google.com/actions/assistant/best-practices
As per my opinion you should go with 1st approach. It is more flexible and scalable.
You would need to make many intents for sure but you would be able to get what user wants to know exactly.
In the 2nd approach, you would need to do many things for which you are using DialogFlow.
Try making conversation flow chart before designing the intents.
Using Dialogflow:
WorkFlow:
Open the Actions Console.
Click on Add/import project.
Type in a Project name, like "actions-codelab". This name is for your own internal reference; later on, you can set an external name for your project.
Click Create Project.
Rather than pick a category, click Skip on the upper-right corner.
Click Build > Actions in the left nav.
Click Add your first Action.
Select at least one language for your Action, followed by Update. For this codelab, we recommend only selecting English.
On the Custom intent card, click Build. This will open the Dialogflow Console in another tab.
2. Test with Dialogflow:
Dialogflow generates and uploads an Action package to your actions project automatically when you test it. To test your Action:
Make sure the Web & App Activity, Device Information, and Voice & Audio Activity permissions are enabled on the Activity controls page for your Google account.
Click on Integrations in the Dialogflow console's left navigation.
Click on the Google Assistant card to bring up the integration screen and click TEST. Dialogflow uploads your Action package to Google's servers, so you can test the latest version in the simulator.
In the Actions console simulator, enter "talk to my test app" in the Input area of the simulator to test your Action. If you have already specified an invocation name and saved your invocation information, you can start the conversation by saying talk to instead.
Note: If you don't see a TEST button, you need to click on the AUTHORISE button first to give Dialogflow access to your Google account and Actions project.
For more information refer below link:
https://codelabs.developers.google.com/codelabs/actions-1/index.html#0

Google Actions integration with dialogflow different behavior from draft to alpha or beta

i created a chat bot with dialogflow (V1) and integrated it with google actions for Google Assistant. My company was supported by Google for all development process.
The first release of the chatbot was deployed for all users before 8 may. All works well and the actual release on Google assistant is working well.
The problem now is if i want update the bot with new actions and features the behavior of the chatbot is different in the simulator from draft state to aplha or beta release.
In the webhook the data provided by dialogflow is different (the logs on the cloud function): in the draft all parameters are set correctly , but when switch to alpha or beta version (created from the draft that works well) the parameters are always empty and all the bot answers are wrong.
There are specific actions to make or settings after 8 May to switch from draft to alpha/beta release of Actions on Google to avoid this strange behavior?
Alpha and Beta releases people made last August used to lack the training (machine learning) the agent received. It may be the case here that your alpha and beta versions have the same problem.

Resources