Hero - Build your bot

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.

![Vimeo - Intro to listeners](//videos.ctfassets.net/2vbtnveccz5s/5JYGGncNwMhqDkkIfDMtUB/40d2ef64472f2ba5d38df235ee67691b/introduction_to_listeners__1080p_.mp4?classes=w60)

## Global listener

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.

### When to use a global listener

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.

### Components

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:

![1-listener](//images.ctfassets.net/2vbtnveccz5s/2mB8OQuOoaeGh9SW21ZPlY/e7bad27cadd8580be43ffe51df254084/1-listener.PNG?classes=w50)

You manage global listeners in the Globals area of your solution:

![global-listener](//images.ctfassets.net/2vbtnveccz5s/4AEivOiveEknqRs2uFReXY/a6ad4add5dd9cf7d5033ffba88a46a64/global-listener.PNG)

### Pre or post matching

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](/studio/reference/input-processing-path).

## Flow listener

In addition to global listeners, Teneo allows listeners on a flow level too. Listeners are often used to extract entities from user inputs.

### Types

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.

| Type | Description | How to add |
| --- | --- | --- |
| **Flow listener** | Listens to all inputs that pass through a flow including inputs that trigger the flow. | Open your flow in edit mode. Go to the 'Flow' tab and select 'Listeners'. |
| **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 trigger or transition. Click on 'Add' in the 'After Match' section to add a listener. |

### Components of 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.

![2-flow listener](//images.ctfassets.net/2vbtnveccz5s/7DICiC3UyxeOMpDxQoY5Y8/87653bbdd22f58f569579f73b7c887cb/2-flow_listener.png?classes=w40)

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](/studio/language-understanding/concepts/attached-scripts).

![3-flow listener tlml](//images.ctfassets.net/2vbtnveccz5s/4hqcPETWI7iPRFIFZSUVJ6/b103b88dbe88ba8285407071db1c451f/3-flow_listener_tlml.PNG?classes=w40)

If you need additional programmatic logic, for example to further process what you have extracted, you can add it to the script field:

![4-flow listener script](//images.ctfassets.net/2vbtnveccz5s/7yLYa4ed3R6f24ulOTpBKX/bb7b9d72a4fb430237b3f13bb0765e06/4-flow_listener_script.PNG?classes=w40)

### Use cases
*   **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](/getting-started/build-a-slot-filling-flow) 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.

!!! If you find yourself creating the same listener on multiple triggers or transitions, you might want to check if you can use a flow listener instead.

## Listeners vs After Match
[After Match](/getting-started/data-actions) 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.

Build - Listeners

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.

![Vimeo - Intro to listeners](//videos.ctfassets.net/2vbtnveccz5s/5JYGGncNwMhqDkkIfDMtUB/40d2ef64472f2ba5d38df235ee67691b/introduction_to_listeners__1080p_.mp4?classes=w60)

## Global listener

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.

### When to use a global listener

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.

### Components

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:

![1-global components](//images.ctfassets.net/2vbtnveccz5s/3zOu1ZmKGjOakU3gy08yqR/d2cd4acfbf9c782ebe3364aedd78abe5/1-global_components.png)

You manage global listeners in the Globals area of your solution:

![2-manage listeners](//images.ctfassets.net/2vbtnveccz5s/62JHWbIeSmH8yb4yxphUiO/3657e7ea19fe3b50a350b11c78d78a0e/2-manage_listeners.png)

### Pre or post matching

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](/studio/reference/input-processing-path).

## Flow listener
Teneo allows listeners on a flow level. Listeners are often used to extract entities from user inputs.

### Types
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.

| Type | Description | How to add |
| --- | --- | --- |
| **Flow listener** | 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. |

### Components of 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.

![3-flow listener components](//images.ctfassets.net/2vbtnveccz5s/WbpU2mDT1bbCedO46LACq/921880f94e334a402720b28826690dc5/3-flow_listener_components.png)

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](/studio/language-understanding/concepts/attached-scripts).

![4-flow listener components pt2](//images.ctfassets.net/2vbtnveccz5s/3iqh32GbtYIwGvsheI8dzZ/5565e467d3d30594a6ecee1696fc1ab4/4-flow_listener_components_pt2.png)

If you need additional programmatic logic, for example to further process what you have extracted, you can add it to the script field:

![5-flow listener components pt3](//images.ctfassets.net/2vbtnveccz5s/7CMJxCci4sBE8mgCTA7Dsa/09445e21b5031057bed0eca9a232ce7f/5-flow_listener_components_pt3.png)

### Use cases
*   **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](/getting-started/build-a-slot-filling-flow) 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.

!!! If you find yourself creating the same listener on multiple triggers or transitions, you might want to check if you can use a flow listener instead.

## Listeners vs After Match
[After Match](/getting-started/data-actions) 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.


Studio Web - Build - Listeners

Listeners

Analyze your bot

Analyze Log Data

Analyzing sessions

Augmenters

Concepts

Extract values with Augmenters

How To

Metadata

Running custom queries

Counting coffees with Metadata

Reference

Teneo Query Language Cookbook

Teneo Query Language Reference Guide

Teneo Query Language Syntax Overview

Teneo Query Language

Data hierarchy

Event

Property

Session

Transaction

How to

Explore session statistics

Find stuck flows

Generate session logs

Locate and view a session

Make use of skip constraints

Make use of sub queries

Query variables

Troubleshoot the Safetynet

Use relative dates in queries

Query Syntax

Command

Constraint

Meta-parameter

Selection

Transformer

Build your bot

Bot design

Best practices

Data footprint

Encrypting user data in sessions

Flow checklist

Plan your bot

Starting a new Teneo project

Writing good answers

Writing good examples

Conversations

Context restrictions

Flow stack

Greeting message

Safetynet

Trigger Ordering

Create a custom order group

Handle ambiguous inputs

Make your bot pro-active

Share information between flows

Use listeners

Flows

Bulk Import

Entities

Junctions

Outputs

Sub-Flows

Transitions

Intent triggers

Variables

Add a script to your flow

Branch at the beginning of a flow

Use TLML Syntax Match

Use a Sub-Flow

Use Bulk Import

Language Understanding

Annotations

Attached scripts

Language conditions

Language objects

Languages

Lexical resources

Libraries

Linguistic Modeling Language

Localization

Match requirements

Used words

Combine Match requirements

Create a solution in your language

Create your own language objects

Find language objects and entities

Localize a bot

Normalize the user's spelling

Optimize language conditions

Recognize plural and singular

Store what the user said

Advanced Condition Coding

Annotations Reference

Condition Syntax Reference

DateTime Handler

Engine Scripting API Reference

Input Processing Path

Language Object Reference

Scripting

Engine scripting API

Groovy basics

Integration manager

Resource file manager

Scripts

Add a Groovy class

Add an integration

Add files to your solution

Annotate user inputs

Anonymize user data

Define a scripted context

Populate output parameters

Store input parameters

Test your bot

Run automated tests

Test your bot with Botium

Dialog Tester

Deploy your bot

Engine API

Versioning and Publishing

Publish your bot

Version Flags

Work with Version Flags

SDK's

Android

JavaScript

Node.js

Getting started

After Match

Extract Entities

Class Manager

Introduction to transitions

Introduction to entities

Deal with Follow-ups

Dialogue and Context Model

Getting started with Teneo

Handle interruptions

Skip conditions

Teneo in 10 minutes

Flows and match requirements

Entities and After Match

Your First Flow

Your First Solution

Optimize your bot

Optimize classes

Improve the balance

Review Inputs

Refine your bot

Debug your bot in Tryout

Use data to improve your bot

Use Teneo's improvement tips

Troubleshooting

My flow doesn't trigger

My flow behaves unexpectedly

I see warnings in Tryout

Suggestions

root

Table of Contents