This post is part of a series of tutorials on conversational forms:
- Part 1: Getting Started
- Part 2: Handling Interruptions and Side Questions
- Part 3: Handling Contextual Questions and Adding NLU
This series of tutorials explains how to implement slot filling or conversational forms in Botfront without code. Botfront forms are based on the Rasa's
FormPolicyand offer the same flexibility and resilience.
In the previous post we have seen how to implement more resilient flows by allowing interruptions and side questions.
In this post we'll improve our assistant ability to support users while filling the form. A user might ask for a clarification directly related to a question being asked. An extreme example is when the same question can have a different answer depending on the context. For example, Why are you asking that?.
The first step is to enable contextual questions in the form.
When you enabled slots, Botfront will set the categorical
requested_slot with the name of all slots in forms as categories.
Adding contextual questions is similar to adding generic question or interruption flows.
The main difference is that the first element of the branch need to refer the slot currently being filled. In the context of the
first_name, all you need to do is to set a condition where the
The video shows how to change our story so our assistant can answer the question Why are you asking that? in context.
You can add more questions by adding branches under the slot condition.
We also need to exclude the why intent from the allowed intents in the extraction tabs of slots.
Now all we have to do is training our assistant and check the result. As you can see the bot can now answerthe question in context.
We added a lot of flexibility and resilience to our form. But we still miss some of the basics: we have assumed until now that users would just type their first name and email address.
But what if someone says Hi, I'm Nathan and my email is email@example.com?
We want our assistant to get the slot value from the right place. If the NLU determines the user is providing their
work_email, then we should take the value from the entity. Otherwise we should just take the content of the message provided it is valid.
In the video we show how to add multiple extraction conditions. We changed two things:
- We specified that the
work_emailcan be extracted from entities if the detected intent is inform.
- We excluded inform from the allowed intents when taking the value from the user message to make sure the conditions don't mix up.
In the previous post we have seen how to handle generic side questions, in this post we extended this approach to contextual questions.