I'm trying to create a mock interview Action that asks a specific set of questions in a specific order, regardless of what the user says in response to each question. How can I set up the intent in Dialogflow to accept any phrase from a user to trigger the next question as the response?
Ex of the dialog path:
User: "I want to practice for an interview"
Google: "Question 1: tell me about yourself"
User: [says literally anything]
Google: "Great job. Question 2..."
User: [says literally anything]
Google: "Okay! Question 3..."
Using Dialogflow, you can create an intent that accepts any input by taking the user utterances and marking them as #sys.any.
Then you can do one of the following:
Use Dialogflow contexts to make the next step dependent on the first (this is good if you want to do everything in Dialogflow)
Keep track of the conversational state in your webhook using the app.data object.
There are a few good ways to handle what you want, the best solution will depend on your other needs.
If you're using a fulfillment webhook, you can handle this as part of the Fallback Intent. Make sure the checkbox to use fulfillment is on for the Fallback Intent, and you'll be sent everything that the user says that doesn't meet other structures. You'll need to keep count of how many times you've been called and you can store this as a parameter in a context, as part of the app.data session storage object, or as part of the app.userStore cross-session storage object. Your webhook will return the next question as a response.
If you want to avoid fulfillments and handle it through Dialogflow, you can use the same general idea, but you will need to keep track of which question you're on for each time. You can do this by creating multiple Fallback Intents with each one having as an Incoming Context a context named after which question you're expecting the user to answer (say "question_1") and the Outgoing Context named after the question that is in the reply (for example, "question_2").
Related
I have an intent with an Assistant List containing two options, Apples and Cheese. I want to provide a different response to each option chosen.
My first attempt was to use follow-up intents for each item, but when I do this I get a “not understood” message when tapping/choosing the item. On reading more, I understand this is because the actions_intent_OPTION event has been fired and there is no intent to handle it.
My second attempt was to add the actions_intent_OPTION event handler to each of my follow-up intents. When I did this, only the Cheese intent was invoked each time. I understand this is because actions_intent_OPTION can only be handled by a single intent.
So my conclusion is that the only way I can provide different responses for different items in an Assistant List is to handle this event with a webhook, and that it’s not possible using Dialogflow alone. Can anyone confirm or point me in the right direction if not?
The answer is, as suspected, that you can’t use an Assistant List purely in Dialogflow, you have to add a handler function in the fulfilment, that fires on the event actions_intent_OPTION. For example:
const option = conv.arguments.get('OPTION');
if (!option) {
conv.ask('No choice made');
} else if (option === 'optionA') {
// Do something
} else if (option === 'optionB') {
// Do something else
}
Follow this ideal approach:
remove follow-up intents
add a new intent with event set as actions_intent_OPTION
enable webhook for the new intent
in the webhook extract the selected option
based on the selected option, pass the required response
If you want to use only Dialogflow, then it won't work! This is because, when you select an option, the output context and the generated event both will be the same as the 2 intents - cheese and apple. There will be no way for the AI engine to decide which Intent should be triggered. Whichever intent is first, it will be called every time.
I tried to recreate what you did all be Dialogflow and even put cheese and apple as training phrases for the 2 intents just to provide some differentiation to the AI engine, but it still selected only one intent.
I am developing api.ai bot and want to create an event that can automatically launch an intent that I had.
Scenario: I have a webhook to check whether the query parameter exists in database or not. If it exists fulfillment text will be "The data exist in the database".
But if the query doesn't exist in the database, it should reply with the "The query doesn't exist. Do you want to add it?
With this response, the followup intent "YES", "NO" should get triggered. How can I solve this?
In a scenario like this, you shouldn't use followup intents (although what you're doing is, essentially, the same thing).
If the query exists, you'll reply as you've outlined.
If the query doesn't exist, you should prompt as you've indicated, but also set an Outgoing Context (for example, named "prompt-add") from your fulfillment indicating that you're prompting to add something.
Then, you'll create two intents that have this Context set as the Input Context - one that accepts "yes" like statements and one that accepts "no" like statements. Handle these in fulfillment appropriately.
In the DialogFlow console, you can set an input and output context for an intent.
I would like to have the same functionality using the Actions SDK.
Since I can set the context in my fullfilment webhook in the code, the output SDK is covered.
However, how do I set the input context for an intent to only trigger if that context was fetched?
I could not find this in the documentation examples.
I don't believe you can in the same way, which is part of why they added Dialogflow.
Although as part of your response you can indicate the ExpectedInput for the next Intent, the documentation for the ExpectedIntent makes it clear that your Intents are only used for speech biasing - you'll always get the built-in TEXT Intent.
In fact, this documentation says that you'll only get custom Intents for the initial call - later Intents are always triggered with a built-in one.
Update: One thing you can do is to include information in the response that will be sent back to you in the next request.
If you're using the JavaScript SDK, this is done with the second parameter to ask() and is available via the getDialogState() function.
If you're sending back JSON, this is done using the conversationToken attribute and is available in conversation.conversationToken in the request object you're sent the next round.
Is it possible to receive the previous message that the user have send to the chatbot (without using quick replies or postback buttons). Example:
User: "Can you call a friend?"
Bot: "Who should I call?"
User: "Tim"
In the API I now have just the information "Tim", without knowing if I should call him or text him or make him a sandwich or whatever. So I basically I want to add some Postbackdata or metadata additionally to the text "Can you call a friend" (intent: 'CALL'), so the message "Tim" will come with that data.
Is there a way without storing the data into a database? AWS Lambda with ClaudiaJs.
I found the metadata field in the FB API which turns out to be the wrong field for that since it is only for communicating between several apps?!
What you are looking for a called a "slot-based bot", or slot-filling, basically meaning that you have a "slot", or blank that needs to be filled in before your bot can perform an action. In your example you have two slots: action and person
Actions could be: call, text, message
Person: name of a person, friend, etc.
I don't think any of the message frameworks (Slack, Facebook, etc) will provide you with the information you need. You will need to build this logic out yourself.
You can look at using wit.ai stories to achieve this.
Look to this similar Stack Overflow question and answer.
You can reverse order of conversation, and at beginning user writes some text or send you something else. After receiving, you should send to user buttonsTemplate, where postbacks will be like "CallTo&Tim" where instead of Tim you can put every text you need to pass to next executor(and you also can store previous user message here). Than just make substring of postback, check it`s type and do whatever you want.
I'm working on a CRUD application using Dancer. One of the things I need to do is check a user is authorized to perform POST (create) and PUT (update) / DELETE (remove) operations.
I've read up on before hooks in the Dancer documentation, but have been unable to figure out the best way to do varying types of authorization.
For a POST operation, all I want to do is check that a valid API key has been submitted with the request, but for a PUT/DELETE operation, I want to check that the API key submitted matches the user who is attached to the record to be updated or deleted.
I understand how to do the logic behind checking the API keys, but I'm wondering if hooks (or something else) would allow me to call that logic without having to add the same boilerplate function call to every single PUT/POST/DELETE function on every route.
like I told the poster on IRC, I think a combination of https://metacpan.org/pod/Dancer#request (the Dancer request object) and its HTTP verbs querying things should do the trick. See for example: https://metacpan.org/pod/Dancer::Request#is_post .
I'm not sure if it's a very elegant solution, but I think it should work.
Here's another take on this issue, based on experience:
Since Dancer has not had the opportunity to parse your input parameters when the 'before' hook executes, you may not have a consistent way to read in your authentication credentials, if your application allows them to be provided in a variety of ways.
In particular, if you're using input parameters to pass a nonce to prevent CSRF attacks (which you should definitely consider!), you won't have a consistent way to obtain that nonce. You could do your own mini-parameter-parsing within 'before', but that could be messy too.
I ran into this problem when I worked on an application some time ago, and remember having to add the dreaded boilerplate authentication function to every PUT/POST/DELETE route. Then, if you're doing that, it becomes irrelevant to check request->is_post because you're already deciding whether to place the boilerplate authentication function within the route.
I haven't tried this yet, but it may be possible to handle the pre-requisite action in your Route base class, then pass upon success. This will leave your specific packages to handle the request as normal once your base class has verified authentication.
An action can choose not to serve the current request and ask Dancer to process the request with the next matching route. This is done with the pass keyword, like in the following example
get '/say/:word' => sub {
return pass if (params->{word} =~ /^\d+$/);
"I say a word: ".params->{word};
};
get '/say/:number' => sub {
"I say a number: ".params->{number};
};