User permission not routing to correct intent - dialogflow-es

I am making actions on google using API.AI and suddenly today my user permission request is not working. Just after the user gives permission, API.AI doesn't route to any intent. Next time when the user says "yes" or "no" then it handles it incorrect intent "permissionhandler". It rather shows some event "assistant_itent_action_PERMISSION" whereas it should be routing to intent "permissionHandler".
Here is how it should

Should be fixed now. Please check.

Related

how can i make the user get back to the previous intent in dialog flow?

I am facing an issue, I have a lot of intents Having (Quick Reply Response), And i want to create a "Back" (Quick Reply) to make the user can getting back to the previous intent.
It does not work correctly. Any Suggestions??
I will be very grateful to you

How to make the chatbot redirect a unknown answer to my email so I can manually answer the problem?

I’m new to Dialogflow and I want to make a chatbot for faq and troubleshooting. I want the chatbot to send me responses that I do not know how to answer so I can manually contact the people whose problems have not been solved. How do I achieve this automatically?
I am assuming you will have different intents for your FAQ system, so that if user asks a question it will be matched to specific intent and bot will send a response according to that matched intent.
Now if none of the intents matched, it will go to Default Fallback Intent where you ca enable the webhook. In the webhook, you can write a function to send email yourself with the user query and other user details so that you can check and reply to the user.
As previously mentioned, you could have your endpoint recognise that the fallback intent has been triggered, but you will also need to obtain the users email which is outlined here Get email from user using Google actions , otherwise you wont be able to get back to the user with a response.

Redirect user to the Default Welcome Intent when he says "cancel" or "exit"

I'm developing a Dialogflow application for Google Assitant. In that, if I say "Cancel" it directly calls the exit_conversation intent where I've specified actions_intent_CANCEL event. So it displays the output specified in that intent and bot exit the conversation.
Instead of exiting the Bot I need to open Default Welcome Intent. Is there any way to do that?
P.S. I'm using Python fulfillment as a backend for this bot.
In short - no, you can't do that.
You're essentially asking that, when the user tries to quit, you don't want to let them quit. From Google's and your users' point of view - that is a pretty unacceptable option.
The CANCEL event handler is fairly limited with what it can do - Google will terminate the conversation, even if you don't specify that the microphone should be closed, but you're given the opportunity to say a final message and offer a link to elsewhere.

Permission response not handled correctly

Following this command in node.js using the ApiAiApp module:
app.askForPermission('To know what day it is where you are',
app.SupportedPermissions.DEVICE_PRECISE_LOCATION);
I get the following in the Actions on Google Simulator.
It correctly prompts for my response, but then is confused and doesn't recognize my answer! Is there something missing or broken in my API.AI agent? After the askForPermission, there are no other fulfillment calls.
The problem is likely that you need to set an Intent that will be triggered when the permission is granted. You do this by setting the Event to actions_intent_PERMISSION.
This will look something like this:
You can set the Action to whatever makes sense for your webhook, and be sure to enable webhook fulfillment for the Intent as well.
If you need to keep track of where the permission request was initiated from, and handle it through a different Action, you can set a Context and have different handling Intents based on different Context settings.
The Fallback Intent method works because there is no better match at that point since you hadn't specified a regular Intent with actions_intent_PERMISSION. It isn't the best choice, however, since it could match other situations from your user.
The concept that I was missing is mentioned here.
All you have to do is create a child fallback intent for the intent
you are requesting permissions from.
So if you have a few intents that ask for permissions, each of them need their own fallback intent.

How to verify a user's pin when they open the skill (LaunchRequest)

I am having some problems with my Alexa skill. I would like the dialogue to go like this:
User: 'Alexa, open party'
Alexa: 'Hello, what is your four digit secret pin?'
User: '1234'
Alexa: 'Confirmed, what can I help you with?'
But I am confused on how to structure this. I need to take the user's pin and verify it in my codebase. I know you cant get dialogue delegation to work inside of the LaunchRequest. The LaunchRequest can not be customized, so I cannot add slots to it. I can't find any other suggestions/examples on the internet. Has anyone done this before or are there any suggestions?
Amazon supports account linking as the method to connect users with their other accounts. This allows users to log into their other account using OAuth at the time the skill is installed. While it may be possible to determine a user based on the session object userid, it may be difficult to get such a skill published.
It turns out that you can not delegate slot collection to Alexa within the LaunchRequest, because it is not part of a valid response type for LaunchRequest.
My Initial logic was:
User says 'Alexa, open party'
Alexa Skill calls LaunchRequest. (At this point I need to ask the user for their pin by delegating Alexa to do slot colleciton)
In the LaunchRequest, immidiately respond with this.emit(':getPinIntent'); where getPinIntent is another intent existing in my Alexa Skill. The above code is what I saw on the internet for how to call another intent without the user having to provoke using voice.
getPinIntent gets called and immediately it checks to see if all the required slots are filled (i.e. if the slot PIN has a value). If they are not and dialogState !== 'COMPLETED' then I delegate the slot collection to Alexa.
The above step (#4) is where things go wrong. Because delegation is not a valid response type for LaunchRequest's, there is no field dialogueState which is required for delegation to Alexa. The Alexa Request is still a LaunchRequest instead of an Intent request because the user did not invoke the intent by saying something to Alexa.
In conclusion this is not a valid way of completing a dialogue where upon launch the user is asked for a pin and then can reply by only saying that pin, visualized below:
User: "Alexa, open party"
Alexa: "What is your pin" (alexa never gets here, because of #4 and #5 above)
User: "one two three four"
Alexa: "Confirmed, what can I help you with?"
If I have made any mistakes or wrong assumptions please let me know.
My current logic has now changed. If you do not use the Skill Builder Beta you can have a slot exist as an utterance for one of your intents. So I now have getPinIntent with a slot called {PIN} and an utterance in the form of {PIN}. This lets the above type of conversation happen because when the user says his or her pin back ("one two three four") it starts the getPinIntent where I can then continue OR delegate the dialogue to Alexa because for IntentRequest dialog is a valid response type.
The only problem I have now is that because I am not using the Skill Builder Beta I can not (or have not found a way) to add Dialogue Models to/inside of my Intent Schema. I have tried copying the JSON text from the Skill Builder Beta into my Intent Schema after adding the correct Dialogue Model, but this always results in build errors.
So now I can complete the user's pin authentication and respond with a "How can I help", but the IntentRequest that comes after that may require delegation to Alexa for slots, and this would cause a crash because without the Skill Builder Beta I am unable to add the appropriate dialogue models for Alexa to use during delegated slot collection.

Resources