Intent triggers

The main role of an intent trigger is to tell Teneo what kind of inputs, or intents, should activate a flow.


Match requirements

Match requirements tell Teneo how and when an intent trigger should match a user input. An intent trigger can contain as many match requirements to express the users intent and variations of it, essentially as many as needed to get the job done. There are a number of different match requirements in Teneo. Match requirements are tested top to bottom in the same order as in the interface.

Which match requirements should I use?
The easiest way to get started with Teneo is by using class match requirements. Once your solution grows you may find a need for syntax triggers. For example, if class triggers have trouble distinguishing between two intents. Or if you need to recognize a very specific pattern. Or perhaps your trigger should include certain specific words, in which case a syntax trigger may be best. You can mix and match triggers, depending on your needs. For more details on how to make the best of both types of triggers, see: hybrid approach in the language understanding section.

Teneo also provides you with a nifty feature. When you tell Teneo what kinds of input should trigger an intent trigger by adding training example, Teneo gives you a 'Generate' button. By using the Generate button, Teneo will attempt to find the best match requirement. Additionally, Teneo will use this data for you when automatically testing your bot!


Class match requirements use the matching done by a machine learning model (a classifier), which attempts to determine what an input is about. While you maintain the classes in the class manager, class match requirements are where you put them to use.

Ideally you would use actual user inputs, but to get started during development you can just use some example inputs that you can think of from the top of your head. We recommend to start with 10-20 example inputs per class trigger. This will result in good performance, but you will notice the model will improve when you add more examples once you start testing and collect more inputs. You can find more details on improving your learning examples here: Optimization of class triggers.

Note that you can also add negative example inputs. Those are not used to train the model however, but they can be helpful when running automated tests.


Condition match requirements (officially called Language Condition Syntax Intent Triggers) use a different method to find out what kind of inputs should activate a flow. They make use of a language condition, which is expressed using a condition syntax. You can either hand-craft the condition yourself, or let Teneo automatically create it for you from a set of examples, after which you can edit the condition. For an example of different ways to create and edit a language condition, go here: How to create a syntax trigger.

The possibility to use both class and syntax triggers provides you with the power of machine learning and the precision of condition syntax. This is what we call our hybrid model. It is explained in depth in the Language Understanding section.


Context match requirements let's you restrict your trigger to only fire in certain contexts, for instance after a certain topic has already been introduced. Consider the following dialog:

User: What is the weather like in Amsterdam?
Bot: It's quite sunny in Amsterdam at the moment, make sure to wear sunscreen!

User: What about Barcelona?
Bot: It's raining in Barcelona. Don't forget your umbrella!

The user's second question can only be interpreted correctly if you know that the topic the user talks about is weather. For this you could create a trigger that fires on inputs like 'What about [city]', but only when the conversation was already about weather. This is what Context restrictions can be used for. Throughout the conversation 'contexts' can be set, which can then be used by triggers as restrictions.

The contexts that you assign may be of different kinds. Often it is confined to the value of a variable that has been set earlier on in the dialog. If the context is hard to represent by means of a single variable value, you can set up a scripted context restriction. As an alternative, you can include Groovy code in the language condition of a syntax trigger.


Entity match requirements will match if an entity is present in the users input.

Language object

Language object match requirements will match if a language object is matched in the users inputs. This is incredibly useful together the language resources, so that you can use the %YES.PHR and %NO.PHR which will match a wide range of expressions where the user expresses assent or dissent.


Script match requirements lets us use scripts to match the users input or a more complex state. For example, we can use script match requirements to check if a frontend has sent a request parameter with a specific value.

Order group

When Teneo tests a user input against your solution's triggers, it does so in a certain order, and stops at the first match that fully satisfies all criteria.

Each trigger belongs to an order group. The triggers of the highest ranked order group will be tested before Teneo moves on to the next order group, and so on. Class triggers all belong to the same group called 'Class Triggers'. Syntax triggers can be added to any order group, and you can create as many groups as you like and order them according to your needs. Typically you'll add the most specific syntax triggers to the highest order group, and a more generic syntax trigger to a lower ranking group.

Inside each order group, the ordering may be further refined, so that the order between individual syntax triggers is specified.

When a syntax trigger is born, it will be stored in the default trigger order group. You can easily change that in the drop-down 'Order Group', in the syntax trigger's 'Examples' panel.

Multiple triggers

Flows can have several independent triggers. Using multiple intent triggers makes it possible to create diverse triggers with different degrees of complexity and specificity linking to the same flow. For example, it is possible to create a flow with an intent trigger with class match requirements and also an intent trigger with a more complex condition match requirement that matches very precise inputs. These triggers can have their own data actions and listeners (to extract additional information from the input) and would have their own ordering.

Was this page helpful?