Turns and Intents
Turns in OpenDialog
Have you read our 'Getting started with OpenDialog' section? If not, we would advise reading that before you dive into the content here as it gives an overview of the concepts behind OpenDialog.
Turns are contained within Scenes and represent the last conversational level for OpenDialog.
A Scene with two Turns
Scene settings view
Turns have two behaviours
STARTING turns are only considered when you join a scene for the first time. After the first interaction within the Scene starting turns are no longer considered.
OPEN turns are considered only after you've joined a scene and they are always considered while you are in the scene.
Turns can be both starting and open at the same time.
Turns contain a set of Response and Request intents. You can decide which participant (the user or the application) should initiate a turn.
You can have multiple intents in the request or response "buckets".
Request and Response Intents
Typically, you would either be using conditions (on application intents) or rely on the interpreters (for user intents) to determine which intent would actually be selected.
You can also only have request intents.
If you only have request intents in a turn one of two things can happen:
- 1.You define a transition in the turn in which case the engine will follow the transition and attempt to find an appropriate intent on the end of that transition. An appropriate intent would be the opposite participant. So if in Turn A the request intent is from the APP we will be looking for intents from the USER in Turn B and vice-versa. This allows you to do cadence switch on transitions to have natural conversation flows.
- 2.You don't define a transition, in which case the engine will go back to the scene level and look for open turns that it could follow that have the opposite participant. So if you had Turn A with an APP intent and no response intents that engine would look for other open turns with a USER request intent to enter. This again allows you to switch cadence, deal with out of context questions such as FAQ, etc or localised no matching.
An intent, from the user, is also referred to as an incoming intent, while an intent from the application is referred to as an outgoing intent. As the figure below illustrates an incoming utterance is interpreted to be matched on an incoming intent, and the Conversation Engine will then select an outgoing intent that we will map (through the message repository) to an outgoing utterance.
Incoming and Outgoing Intents
Request Intent Settings
Intents have a number of settings to help us manage it:
The sample utterance is the phrase we use in the conversation flow and in the conversation designer to remind us of what content the intent is supposed to support in the conversation.
The Intent Name is the more formal name for the intent that we use to refer to it through interpreters (for incoming intents) or in the message repository (for outgoing intents). A good naming format to use for this is
intent.user.<name of intent> for user intents and intent.app.<name of intent>for app intents. However, feel free to use whatever makes sense for your better understanding of the flow. The Interpreter indicates which interpreter we will be using for the intent in question, while the confidence level determines the minimum confidence level acceptable for the intent.
Yes, Intents have behaviours as well! Intents currently just have the COMPLETING behaviour, which means that if the intent is matched it will also mark the conversation as completed. A completed conversation will take us back at the top of the scenario and look for another way in through STARTING conversations, scenes, turns, etc.
Intents can also cause transitions. What this means is that if the intent is matched it will cause a transition to another Conversation or Scene, and the Conversational State will pick up from there.
Within each intent you can add the following advanced settings to an intent:
- Expected Attributes: You can add Attributes to an intent, by adding them it tells the system to save the specified attributes in the given context e.g.
First-namein thesessioncontext. If not set, attributes will always be saved in theusercontext. You can read more about Attributes here. - Conditions: You can add conditions to intents to only show specific intent based on certain criteria. If a condition that has been added is met, then it will show the intent e.g. if we only want to show this intent to new users then we would set a condition such as
seconds_since_last_seenwith the operation set toLess Thanand the value set to0- Meaning only user that have never interacted with the application will see this intent. More information will soon be available on Conditions. - Actions: We can also add actions that will have been define in the 'Action' section. As so, if this intent is selected, the named action will be run. More information will soon be available on Actions.
Some intents have special meanings in OpenDialog so it's worth highlighting those here:
This intent is mapped to an event from webchat - it is called whenever webchat loads for a new user and provides a way to kickstart the conversation. It is automatically set as a Request Intent of the Welcome Scene's Welcome Turn.
This intent is fired when users click on the "Restart" button in webchat. It is automatically set as a Request Intent of the Welcome Scene's Welcome Turn.
This intent is fired when users click on the "End Chat" button in webchat.
If no interpreter is able to provide a positive interpretation of a user utterance the Conversation Engine will generate a TurnNoMatch intent and attempt to find a Turn within the scene that can handle it.
If no turn within the current scene handles the
intent.core.TurnNoMatch the Conversation Engine will generate a Scene No Match and escalate a level above to try and find a match for that. If no scene within the current conversation handles the
intent.core.SceneNoMatch the Conversation Engine will generate a Conversation No Match and escalate a level above to try and find a match for that. This intent is fired by the Conversation Engine whenever all interpreters return a no match and no lower-level No Matches (described above) were caught.
Currently, this is automatically set as the Request Intent of the No Match Turn in the No Match Conversation.
Last modified 1yr ago