Listeners help your bot pick up relevant pieces of information from user inputs, even when these have not been explicitly prompted for. You can think of a listener as a fly on the wall, silently listening and registering things.
Global listeners listen to any input, independent of the flow.
Just like flow listeners, global listeners help your bot pick up relevant pieces of information from user inputs, even when these things have not been explicitly prompted for. You can think of a listener as a fly on the wall, silently listening and registering things. However, global listeners listen to any input in a conversation, whereas flow listeners only listen to inputs that trigger or pass through a particular flow.
It can be very tempting to use a global listener any time you want to pick something up from an input. For example, you could create a global listener that stores the name of a user in a global variable 'userName' whenever a name is encountered in an input. However, this is generally not a good practice. Because the global listener operates on each input, it might accidentally overwrite 'userName' with any name, like the name of the user's sister for example. In general, it is best to use a flow listener for the flow where you specifically anticipate receiving a particular detail and only use global listeners to listen for things that transcend flows.
Global listeners are made up of the same parts as flow listeners: a TLML Syntax condition and an Execution Script. The Syntax condition determines what patterns should be listened for, e.g. a positive sentiment. The Execution Script defines what should happen when the Syntax condition is met, for example updating a counter or adding an annotation. An example of a global listener that counts the number inputs in a conversation that express a positive sentiment could look like this:
You manage global listeners in the Globals area of your solution:
There are two types of global listeners, pre matching listeners and post matching listeners.
- Pre listeners - Pre matching listeners listen to inputs before Teneo tries to match the input to a trigger or transition. This makes them best suited when you want to do things that are important during matching. For example, you can use them to add annotations that can then influence if a particular trigger or transitions should match. For example, a pre matching listener can annotate a postal code in an input and a language condition might say 'you should only match if a postal code is present in the input'. Because the annotation is added before Teneo tries to match the language conditions, the annotation will be taken into account.
- Post listeners - Post matching listeners act on inputs directly after Teneo finds a matching trigger or a transition waiting for a new input. You can't use these to do things that are important during the matching process, because by the time the post listeners are executed, the matching process is already completed. You can use them, for example, to check if the currently triggered flow was stored in a particular folder, like the 'Flows' folder. If true, the listener would then perform the task specified in the listener's operation.
You can find more details about the order in which Teneo executes listeners (and other tasks) in the Input processing path reference.
Teneo allows listeners on a flow level. Listeners are often used to extract entities from user inputs.
When you add a listener to a flow, you can choose to make it listen to all inputs that trigger or pass through the flow or to make it only listen for a particular trigger or transition.
|How to add
|Listens to all inputs that pass through a flow including inputs that trigger the flow.
|Open your flow in edit mode. Click on the 'Listener' icon located under the minimap.
|Trigger / transition listener
|Is defined in relation to a specific point of a flow; will only kick in for inputs of the trigger or transition where the listener was added.
|Open your flow in edit mode. Select the Plus icon, below the trigger or transition. Hover over 'After Match' to add a listener.
A listener is made up of two parts: a TLML Syntax condition and an optional Execution Script. The Syntax condition determines what patterns should be listened for, e.g. the name of a city. The operation defines what should happen when the condition is met, e.g. setting a variable or updating a counter.
Sometimes you can extract the information you want in the TLML Syntax condition itself. In that case, you don't need to specify a script. In the example below, the listener extracts the destination mentioned in the user input. Read more on how to extract data from inputs here.
If you need additional programmatic logic, for example to further process what you have extracted, you can add it to the script field:
- Flow listeners are defined for a flow and listen to all inputs that trigger or pass through a flow. They are generally used when your bot should pick up certain pieces of information wherever they are mentioned in the flow dialogue. Slot filling flows typically make use of flow listeners.
- Trigger/transition listeners are attached to a specific trigger or transition of a flow. A trigger/transition listener can be the best solution when you need to pick up something that can be interpreted differently depending on where you are in the flow. For example, if a flow should pick up two dates from a user (like an arrival and departure date for a holiday), you can add a listener to the transition where the user is asked for the arrival date and another listener to the transition for the departure date.
After Match are great if you know exactly:
- What you want to extract from the user input
- When that information is present in the user input
However, the above conditions will not always be met. There will also be cases where the user input contains information that the bot has not yet asked for. Consider also a case in which we want to use a Global Listener to extract information. In cases like these, we can use Flow Listeners combined with propagation scripts in order to add programmatic extraction logic. This enables us to extract the information we need at any point in the conversation, rather than just when we are expecting it, and to propagate the value to a Global Listener.