I'm a bit confused about how to handle the following scenario:
The user triggers the FooBarIntent whose fulfillment requires a linked account from a third party.
I manually call the signin helper from my fulfillment code.
The user authorizes my agent, Actions on Google sends the helpers response with the signin status to Dialogflow, where a SignIn intent picks it up and passes it to my fulfillment service.
Now how do I proceed with fulfilling the original FooBarIntent? I thought this would somehow be handled seamlessly, but the signin helpers response is an entirely new webhook request with no information about the original request. It seems that I could store that information in a context, but that seems rather clumsy. Am I missing something here, or do I really have to tell the user something like "thanks for logging in, now please ask your original question again"?
Saying "Now please ask your original question again" is certainly the wrong approach to take - you have that part correct.
You're also correct that there is no automatic re-triggering of the original Intent. While this seems odd, it is simply because Intents represent what the user has said - not what you're going to be replying with. Both the user's initial statement and their sign-in acknowledgement are separate things that the user has said, and you may wish to handle each differently.
As you suggest - one thing that makes sense to do is to respond to the initial thing they said before you got the results from the helper. In these cases, saving the Intent or Action name and parameters in a context when you request the helper can let you pick back up afterwards. (There are other possible behaviors, however, that could make sense. Consider, for example, if you request sign-in as part of the welcoming intent. Since the user never gets past this first step, you don't need to keep track of the state.)
This pattern of saving the state when you take a detour to get the sign-in is one that is directly supported by the multivocal library, for example. With multivocal, you specify the requirements necessary before an Intent or Action handler is triggered (such as requiring the user to be authenticated). It takes care of meeting those requirements and then making sure the conversation continues where you left off to take the detour.
Related
We are implementing our customized chatbot using dialog flow. When user enters any text, our javascript code sends this text to our python server and the server interacts with google dialog flow and server gets complete response. I just have couple of questions as below.
When server gets the response from dialog flow, it will process the
response and sends some response to UI. Do we still need to have
fulfillment enabled as our server is getting response? Basically if
server is interacting with dialog flow and getting response, what is
the use of webhook?
Is there anyway to enforce the dialog flow intents require at least
one of entities? I went through Can I make Dialogflow intents require atleast one of the trained entities? which says to enable webhook fulfillment for that intent and if no entities were provided, re prompt the user for at least one of a list of entities. So in my case, if webhook is not needed, do I need to do it in the server once server receives response or is there anyway dialog flow will automatically enforce the condition with out server taking the responsibility?
In your case, no, you don't need to use webhook fulfillment.
You may still wish to use it, however, if you want to separate business logic (which would be in the webhook) from UI/UX logic (which would be in your python server and in the javascript client). But there is no requirement that you separate things this way.
Similarly, you can use your python code to enforce "at least one of" the parameters matching - you're moving that logic from the webhook into your existing server.
Either way, this is a bit kludgy. One alternative if you have different entity types is to have multiple Intents, one for each possible type, and to mark the parameter as required. This way the Intent will only match if the parameter is provided. If you then need to report each of these Intents as the "same" Intent, you can add that logic to your python code.
So I have a flow prepared.
User: I would like to book an appointment
Bot: Sure. Does 3pm works for you?
User: Yes
Bot: Great. Appointment has been set. (Response from Fulfillment)
Bot: Anything else you need help with? Yes | No (How to achieve this)
I have tried triggering followupEvent but that won't display any response till the chain of intent is complete.
When the followupEventInput parameter is set for a WebhookResponse,
Dialogflow ignores the fulfillmentText, fulfillmentMessages, and
payload fields. When Dialogflow receives a webhook response that
includes an event, it immediately triggers the corresponding intent in
which it was defined.
I have End Intents ready for response for Yes and No. But need help in triggering it.
An intent shouldn't be used as a step in your flow or be tied to a single response, its intended to represent a category of phrases your user might say to complete a certain goal in your conversation. Since the was this helpful isn't triggered by any user phrase, but more as a trigger for the user to continue the conversation shows that it shouldn't be a separate intent.
Having the was this helpful phrase be available to multiple intents is a good choice so it can be used throughout your conversation, but I would recommend saving this phrase in a file, an API or a CMS and retrieving the response via code.
I'm not a PHP developer, but I expect it to be along the lines of: responseService.getResponse("requestFeedbackPrompt");
This allows you to retrieve the was this helpful phrase throughout your code, without making the mistake of making a seperate intent for it, as this will create problems later on with keeping state.
If you would decide to go with a single intent for this, you will quickly see that it will become difficult to maintain track of context, states and which step of the conversation you are in as multiple intents will go through this generic intent.
What would you do if you need a different variant of the was this helpful response, with the single intent, you will end up creating an intent for each variation and you will have to align the conversation flow and state accordingly every time.
If you use the service, you just call responseService.getResponse("OtherFeedbackPrompt);`
Hi have something similar in one of my bots. I have taken a different approach to those mentioned.
My bot asks if there's anything it can help with at the end of a an acknowledgement fulfilment.
The customer then has the option to respond with Yes or No.
Within the page that asks the question I have created routes.
One route for Yes and another for No.
The Yes route directs customers back to the point where they can start making selections. The No route provides a fulfilment to the customer and ends the session. I have used Yes and No intents for these.
I was just wondering about the best way to handle when a users intent cannot be understood multiple times.
e.g. In the case of a chat bot a user may enter an intent that cannot be understood multiple times, after the third time I would like the chat bot to call a webservice.
What is the best way to handle this scenario? Possible scenarios I have come up with are:
1) Each time the default fallback intent is called we call a web service that keeps track of the number of times the default fallback intent has been called for the current user and on the third time call another service.
2) Chain multiple default fallback intents together in DialogFlow and on the call to the third fallback intent we make the call (Is this even possible or a good idea?)
3) Keep track of the number of times the default call back is called within DialogFlow (By using an Entity I believe) and then on the third attempt we call the Web Service.
Any recommendations or ideas happily received as I am new to DialogFlow
If you mean "Followup Intent" in (2), this would be a bad idea. Just about anything involving chains of Followup Intents are a bad idea.
I'm not sure how you would pull off (3), to be honest. Dialogflow itself has very little ability to include logic of this sort.
The best approach is (1) - for everything, call your fulfillment webhook and have it handle the logic. Typically, you want to count consecutive times the user hits the Fallback Intent, rather than the total times you do so. You can keep this counter in a short-lived Context.
(Libraries such as multivocal keep track of the counter for you, as an aside, and let you use it in responses or in other logic handling.) (Disclaimer, I'm the lead developer for multivocal.)
I’m building an agent on API.ai where I ask a user a question. I’m not expecting them to answer the question back to my agent. However they may wish to follow up this question later on by asking for some more information. If I ‘end the conversation’ in my intent they can’t then do something such as say ‘tell me more’ without invoking my action again from scratch (in which case all context is lost), but similarly if they don’t say anything, then (on google home at least) the question gets repeated as it's expecting a response.
Is there anyway I could do this?
Actions are conversational experiences. Typically your app would ask a question and the user would provide a response. Once the user exits your app, the conversational context goes back to the assistant.
If you want to provide a quick way to let the user engage with your app again, then consider implementing support for deep links: https://developers.google.com/actions/apiai/define-actions#define_additional_actions
In addition to what Leon has said, you could also manage the context of the user yourself (instead of relying on API.AI's Contexts) and key off the anonymous userid that you get with each request.
This way they can deep-link back to ask you a followup question, and you know "who" is returning and where the conversation last stood when you gave a reply.
I understand that what you basically want is to create an intent in which what the user will say is not predictable (they may not say anything at all).
In that case , you can simply end the response with a prompt to specify it. "...Do you want to ask something more ". If user says "no" , end the conversation in a different intent. Otherwise carry on with the flow.
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.