I'm using Bot Framework Composer v2.1.2 and I created an intent "Cancel" with following trigger phrases:
cancel
quit
abort
exit
never mind
forget about it
back
However during conversations when user is answering multiple choice questions (yes/no) LUIS also treats these answers as Cancel intents.
Is there a way to tell LUIS to ignore specific phrases?
I am aware that I could block interruptions for those multiple choice questions but that would impact user experience.
Have you tried increasing the confidence score like below?
You could also create a 'None' Intent Recognized Trigger try routing the words you want to ignore to it.
Related
I am following the MS documentation for sequential conversations
https://learn.microsoft.com/en-us/azure/bot-service/bot-builder-dialog-manage-conversation-flow?view=azure-bot-service-4.0
This is working fine, but I want to be able to run more than one of these.
For example to ask the following:
"I want to open a technical support case"
"I want to update my technical support case"
"I want to close my technical support case"
The example just revolves around just running one conversation so I don't know how to cater for multiple conversations.
Your help is much appreciated.
Thanks
Steve
Consider looking over using component dialogs, described here. Component dialogs offer a means to branch conversations to handle specific portions of conversation and then return the user back to the main dialog.
In your case, you would query the user to what they are seeking as part of the main dialog. Then, once determined ("I want to close my technical case"), the dialog would branch to handle that specific conversation. After the case is closed, the component dialog would end and return the user back to the main dialog to determine if they want to perform any other actions.
This sample, 43.complex-dialog, demonstrates how to setup a bot to utilize using component dialogs.
If you couple that with LUIS to handle user intents, you should easily be able to manage a user's path while they navigate thru your bot. "I want to open a case" and "I want to close a case" would return either an "case open" or a "case close" intent which, when the intent is returned to the bot, would trigger the associated component dialog to open.
Hope of help!
what is the best way to enhance a dispatch model in LUIS, as checking the dispatch app asked utterances "review endpoint utterances" and updating it does not affect the original apps I have from Luis or QnA, should i always update the other apps manually based on the received endpoint utterances or there is a better practice for improving a dispatch bot?
Good question. Updating Dispatch app directly on LUIS portal is not currently recommended as the utterances added directly will be overridden (removed) when Dispatch app is refreshed via the "dispatch refresh" CLI command. To add utterances shown in "Review Endpoint Utterances" to Dispatch, add them to a file (one line per utterance, one file per dispatch intent). Add the intent file to Dispatch as source, ie:
dispatch add -t file -f <> --intentName <>
If the utterances are never seen in the underlying LUIS app, add them directly to the app.
The Review Endpoint Utterances page shows you utterance by users and your tests as well, which you can quickly assign to intents to improve the model. To make changes to the model visible, you need to first Train then Publish
What is a proper way to handle AdaptiveCard action on the client side using DirectLine? Should I build "value" for activity by hand?
If so, I realized that multi-select's value is handled in different way for different channels (BotFrameworkEmulator sends the values separated with commas while WebChat uses semicolons). Which format should I pick? Isn't this inconsistency a bug?
The Emulator is in a sense a form of WebChat. I don't think the inconsistency is a bug, but if you see WebChat in different places then it's likely to be different versions and may therefore have different behavior.
Fortunately your bot code is free to interpret the received values however you want it to. If your bot is likely to run on multiple channels then you may want to make your bot smart enough to account for multiple possible choice-separators. Otherwise you can just make sure your bot is looking for the right separator for the channel you want to run it on.
As far as I can tell commas are the more standard up-to-date separators, so it's probably best to go with those. But if you're making your own Direct Line client then it's ultimately up to you how you format the activities that your client sends to the bot.
I would say that the inconsistency is not a bug, it is just the way the data is sent back by different channels. Please remember, Adaptive cards are a fairly new concept of exchanging data between the user and the bot code. It is still going to take time how the values are rendered and posted by each channel to come to a common format. That being said, I would not over think this problem much.
The design pattern for the bot should always be made after fixing the channels that the bot will be published on. Once the channels are fixed then it would just be matter of coding to handle the various ways in which the post back data is sent back to the bot
I want to create something in Slack that sends a message (starting by calling someone with '#') to a channel when specific users login. I've checked ifttt and zapier. I also checked the slack api to create something myself, but I couldn't really find anything usefull.
Anyone has any ideas?
Slack does not track user login or logoff in a traditional sense. Instead, users are always always "logged in" and available to receive messages once they have joined a team / channel.
There also is the concept of "presence", which is related, but not the same thing. User presence can change multiple times during a few minutes, e.g. if the user is on a mobile. I am guessing you would not want to send the user your message that often.
Still you can poll the presence information of a user with the API users.getPresence , which could be used to implement a script that polls this information on a regular basis and send your message. You also want to filter out presence changes below a certain duration threshold.
Keep in mind though that the rate limit for API methods is 1 per second. So depending on how many users you have in your workspace there will be a significant delay between the user becoming "present" and your script being able to send the message.
There is a workaround for that to have a google sheet as a database for the users and you can trigger by day once and timestamp it.
So the best trigger is a private message or public and you can use filter when mentioning or signin or signout it depends on the trigger word then you pass the filter since zapier won't count your zaps if you used fiter as a second step.
I am creating a bot using MS Bot framework - NodeJs. The below information needs to be captured for logging (Using the bot.use method i.e. IMiddleware).
Receive:
a. UserId
b. UserInput (text)
c. ConversationId
Send:
1. Name of Intent or dialog name that handled this (that handled the user input text)
2. Bot output text
3. ConversationId
4. UserId
I am unable to get the required detail for the 'send'. Can anyone provide me some suggestions on this.
Thanks.
I believe your main struggle is to log the name of intent or dialog. You won't know it in your send middleware if you haven't captured it during the routing phase. Once the Bot Framework figured out where to send the incoming message, it just invokes that function.
These two articles may help you get what you want. Just recently I played with capturing the conversation's breadcrumbs and also logging a full transcript:
http://www.pveller.com/smarter-conversations-part-3-breadcrumbs/
http://www.pveller.com/smarter-conversations-part-4-transcript/
If you need to build a reliable capture engine, I would suggest that you didn't use the session.privateConversationData like I did and instead built your own storage/log infrastructure to push the events to. Just stream them out with a timestamp and conversationId and reconcile on the other end later. The asynchronous nature of everything the bot framework does internally will be haunting you along the way so that's why. Plus, once you scale out beyond testing on a few users and your bot spans multiple processes, you will be out of the single-threaded event loop.