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

![trigger-3](//images.ctfassets.net/2vbtnveccz5s/hwmlguw17qMIWFebEwocZ/57581cf260f3488e0646d96de0ecfab9/trigger-3.png?classes=w50)

## Match requirements

Match requirements (referred to as Match in Studio) tell Teneo how and when an intent trigger should match a user input. An user intent can contain as many match requirements to express the user's intent (and variations thereof) 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 should I use? 
The easiest way to get started with Teneo is by using Class Match. Once your solution grows you may find a need for TLML Syntax Match, such as if Class Intents have trouble distinguishing between two intents or you need to recognize a very specific pattern. Or perhaps your trigger should include certain specific words, in which case TLML Syntax Conditions for triggers 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 [match requirements](/studio/language-understanding/concepts/match-requirements) in the [language understanding](/article/build#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 examples, you can click the 'Generate' button. By using the Generate feature, Teneo will attempt to find the best match requirement. Additionally, Teneo will use this data for you when automatically testing your bot!  

### Class
Class Match uses 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 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 off the top of your head. We recommend starting with 10-20 example inputs per Class Intent. 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](/article/optimize).

!!! 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](/article/build/test-your-bot/run-automated-tests).

!!! Teneo brings generative AI copilot features to be used at development time. These features include generation of training and test examples. See more on how to set up these features in Studio [here](/documentation/7.4.0/home/teneo-7.4/teneo-studio#teneo-studio_generative-ai_studio-account-page) and how to use them to generate training and test examples [here](documentation/7.4.0/home/teneo-7.4/teneo-studio#teneo-studio_generative-ai_generate-examples_user-intents---desktop-only).

### TLML Syntax
TLML Syntax (officially called *Teneo Linguistic Modeling Language Syntax*) use a different method to find out what kinds of inputs should activate a flow. They make use of a [language condition](/studio/language-understanding/concepts/language-conditions), which is expressed using a [condition syntax](/studio/reference/condition-syntax). You can either hand-craft the Syntax Condition yourself, or let Teneo automatically create it for you from a set of examples, after which you can edit the Syntax Condition. For an example of different ways to create and edit a language condition, go here: [How to create a conditional match requirement](/studio/conversations/how-to/share-information-between-flows#update-the-user-wants-to-order-a-coffee-flow).

The possibility to use both *Class* and *TLML Syntax* match requirements provides you with the power of machine learning and the precision of condition syntax. This is what we call our [hybrid model](/article/build#language-understanding). It is explained in depth in the [Language Understanding](/article/build#language-understanding) section.

### Context
Context Match lets you restrict your trigger to only fire in certain contexts, for instance after a certain topic has already been introduced. Consider the following dialogue:

> **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 is talking about is the weather. For this you could create a trigger that fires on inputs like 'What about [city]', but only when the conversation was already about the 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](/studio/conversations/concepts/context#variable-based-context) that has been set earlier on in the dialogue. If the context is hard to represent by means of a single variable value, you can set up a [scripted context restriction](/studio/conversations/concepts/context#scripted-context-restrictions). Alternatively, you can include Groovy code in the language condition of a syntax trigger.

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

### Language object

Language object Match will match if a language object is matched in the user's inputs. This is incredibly useful together with 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

Script Match lets the developer use scripts to match the user's 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](/studio/conversations/concepts/ordering), 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. Typically you'll add the most specific 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 triggers is specified.

When a 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 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 and also an intent trigger with a more complex TLML Syntax Match that matches very precise inputs. These triggers can have their own data actions and [listeners](/article/build/conversations/concepts/listeners) (to extract additional information from the input) and would have their own ordering.


Build - Intent Triggers

Intent Triggers

Teneo's model for understanding language provides us with multiple ways to recognize an intent using [Match](/studio/flows/concepts/triggers) in triggers.

![3 matches](//images.ctfassets.net/2vbtnveccz5s/1YLiXdkSyoSaIixSRlVf0Z/0992bc12e23a9d337c837aed37835827/3_matches.png?classes=w60)

!!! More information on Match can be found [here](/studio/flows/concepts/triggers#match-requirements)

## Class Match

Classes use machine learning to determine what an input is about. You train a class by providing training phrases (called 'learning examples' in Teneo) in the [Class Manager](/getting-started/class-manager) that are as close to real user inputs as possible. You can either create your own Class or let Teneo generate one for you as seen [here](/getting-started/your-first-flow#populate-the-trigger). Training and test examples for classes can also be generated using Teneo's copilot features, as seen [here](article/getting-started/class-manager?client=studioWeb#generate-examples). We recommend starting with 10-20 example inputs per class.

## TLML Syntax Match

Teneo Linguistic Modeling Language (TLML) Syntax Matches use a [language condition](/studio/language-understanding/concepts/language-conditions) to understand what users are saying. The TLML Syntax Match is expressed using Teneo's [condition syntax](/studio/reference/condition-syntax). TLML Syntax Matches look at words used, their order, synonyms, and other linguistic properties to understand what an input is about. A language condition to cover inputs like 'I would like to order an espresso' could look like this, for example:

```tlml
%HOW_DO_I_BUY.PHR & %COFFEE.NN.SYN
```

You can either hand-craft a language condition yourself, or let Teneo automatically [create it for you](/article/build/flows/how-to/use-conditional-match-requirements#generate-a-condition) from a set of examples, after which you can edit the condition.

## Language Object or Entity Match

Just like the TLML Syntax Match, the Language Object and [Entity](/article/build/flows/concepts/entities) Match use a single [Language Object](/studio/language-understanding/concepts/language-objects) as conditions.  
An example of each can be found here:

*   [Language Object](/studio/conversations/how-to/create-a-custom-order-group#create-a-new-flow-and-add-a-match-requirement-for-a-language-object)
*   [Entity](/getting-started/build-a-slot-filling-flow#configure-the-transition)

## Which Match should I use?

The possibility to combine all of the Match Requirements provides us with the power of machine learning and the precision of condition syntax, but it can be difficult to determine which trigger to use for which purpose. The following are suggestions that can help us make the best of the intent.

!!! Note that Match Requirements can be used in both Triggers and Transitions.

### Classes only

The class matches are the 'go-to' use for Triggers when creating a flow. When the class is performing as intended, the flow is triggered correctly.  
If you find that the class is a bit too greedy, i.e. triggering on too many inputs, you can require a higher *confidence* by adding a context restriction __Class Confidence Medium__ or __Class Confidence High__. This is demonstrated in the page on how to [combine match requirements](/studio/language-understanding/how-to/combine-match-requirements).

!!! A flow can have multiple class triggers. This allows us to attach [listeners](/studio/conversations/concepts/listeners) to each trigger and apply different confidence levels.

### Classes and TLML Syntax

When the Class match is performing well, but we also have a language condition that we trust more (specifically using Entities or rich synonyms), we may choose to add both a class and a corresponding match requirement to our flow. In this case, it could be one [Entity](/article/build/flows/concepts/entities) that might be valuable to cover, or an advanced set of words using a [Condition](/studio/language-understanding/concepts/language-conditions) in addition to adding training examples to your class.

The trigger, in this case, should be stored in an order group above the order group containing the trigger with the Class Match Requirement. This way, the Conditional Match Requirement trigger will be evaluated first. If an input happens to not be caught by the Condition created by the user trigger, the trigger with the Class Match Requirement might catch it. Having both a trigger with a Conditional Match Requirement and a trigger with a Class Match Requirement also has the advantage of allowing us to easily improve the performance of the flow by adding more training data to the trigger (without updating the language condition of the other trigger).

If necessary, we can increase the *confidence* of the class by applying the pre-defined [context restrictions](/studio/conversations/concepts/context#predefined-context-restrictions) 'Class Confidence Medium' or 'Class Confidence High'. We can do this if the class trigger turns out to be too greedy.

!!! More information on creating a new context restriction can be found [here](/studio/scripting/how-to/define-a-scripted-context).

### TLML Syntax only

You can choose to not use a class at all for certain intents. This is a good approach when the classes created is not performing well enough, it is stealing inputs, or it is confusing the solution model, for example. A language condition is much more reliable in such cases. Examples are [follow-up](/getting-started/deal-with-follow-ups) triggers, or triggers that should trigger when inputs consist of just a [particular keyword](/studio/conversations/how-to/create-a-custom-order-group#create-a-new-flow-and-add-a-match-requirement-for-a-language-object) (or synonyms thereof).

If the language condition of the Match is very precise, matching on very specific inputs, we will most likely want to add it to an [order group](/studio/conversations/how-to/create-a-custom-order-group#adjust-the-group-ordering) above the other triggers' groups. This will prevent a less precise trigger from accidentally catching the input from this trigger, which is more precise.

If the trigger is fairly broad, on the other hand, and we want other triggers to be evaluated first, we can add it to an order group below the precise trigger's group. This will prevent the broad language condition from inadvertently catching input that could have been caught by a more precise trigger. More information on ordering can be found [here](/studio/conversations/concepts/ordering).

!!! Note that TLML Syntax Match triggers cannot be improved using the [Optimization](/article/optimize/refine-your-bot/how-to/improve-your-class-triggers) panel, or by just adding example inputs to the trigger. To change the behavior of a trigger with a TLML Syntax Match, you need to modify its [language condition](/studio/language-understanding/concepts/language-objects).

### Combining Matches
This in essence is a combination of the Matches available to an intent trigger. The trigger uses a Class Match on top of having a Condition/Entity/Language Object Match, plus some TLML Syntax constraint. We use this when the trigger is performing OK but we specifically need to constrain the current class with some conditional part.

For example, a trigger 'I love you' includes a Class Match 'I_LOVE_YOU' with 20 training examples. Adding a Condition allows us to force the intent containing the word 'you' and not trigger when using a negation like 'I **don't** love you' using the following condition on top of the Class Match:

```tlml
%YOU.REC & !%NEGATION.REC
```

!!! Combining Matches is also supported in transitions.

Since these triggers make use of an intent trained by a class, we can still improve this class using the [Optimization Panel](/article/optimize#optimize-classes).


Build - Match Requirements

Match Requirements

There may be cases where you'll need to transfer information from a 'Language Object' to a flow, or you need to define a specific condition to be met before the flow executes a script. For these cases, After Match actions are the easiest choice. Simply put, After Match actions are used when you want something to happen at a particular flow node; this can range from setting the value of a variable at that point in the flow to triggering a listener.

One example of After Match actions was mentioned earlier in the [Extract Entities](/getting-started/build-a-slot-filling-flow#extract-information-from-the-entity) page where an After Match action was used on an [entity](/studio/flows/concepts/entities) to get the type of coffee ordered by the user.

After Match actions are not limited to use with entities. There are four different ways to use After Match actions:

*   Entity
*   Language Object
*   Listener
*   Script

After Match actions can be found inside a flow, located on the lower right corner when selecting a trigger or a transition. Which options are available will vary depending on which type of After Match action is chosen. This page will explain these types in depth.

![after match](//images.ctfassets.net/2vbtnveccz5s/5W40qgZespVCiIaTddQr3o/cba3093d9835b9783bf5ba39034cefe8/after_match.png)

!!! Note that a After Match action is only optional, where the input is not forced to trigger it. Once triggered, After Match actions will execute your Mapping or Script depending on which you've selected. If you want it to be required, you'll need to add a Match Requirement with an identical condition.

### After Match actions on an Entity

As demonstrated in [Extract Entities](/getting-started/build-a-slot-filling-flow#extract-information-from-the-entity), it is possible to use After Match actions to extract the values stored inside an entity. If the user selects Entity as After Match actions, they'll need to define which Entity they're interested in. Once that's defined, the user will have the option to 'Add Mapping' and transfer the values from 'Source' to 'Target'.

![d entity](//images.ctfassets.net/2vbtnveccz5s/782dJ1mX53CAG1CGcC9zS2/af7bbc6ff1f838197a12120a240bf432/d_entity.png?classes=w50)

### After Match actions on a Language Object

There are some cases where the Language Objects store NLU values inside them. The user has the option to access these by using After Match actions on Language Objects. While selected, the user must define which Language Object they're interested in. Once that's defined, the user will have the option to 'Add Mapping' and transfer the values from 'Source' to 'Target'.

![d LO](//images.ctfassets.net/2vbtnveccz5s/47dpBnWayR6gy7uEPmNHe2/03af583a114ac47b8b2b7f5645fffb36/d_LO.png?classes=w50)

### After Match actions on a Listener

In cases where using After Match actions on Entity isn't the best option, the Listener is there to help. Together with the listener, you'll have the option to combine both entities and language objects to execute a script or order. When selected, the user has the option to define a Condition that should trigger the Listener followed by an Execution Script, which is executed as soon as the Condition is met.

![d listener](//images.ctfassets.net/2vbtnveccz5s/4siAxwjJM6YLG9iEZHJEBx/6fd428d1305949dca9cba9ffb0d3a8fa/d_listener.png?classes=w50)

### After Match actions on a Script

Teneo supports coding done in Groovy. This After Match action allows the user to use Groovy-based coding on a Script to be executed once the After Match actions are triggered. The user has the option of writing an Execution Script, which will be executed once the After Match actions option is met.

![d script](//images.ctfassets.net/2vbtnveccz5s/5ElZl1UKoVBbhbzWosTQbU/bd4334a6d3a928cb3669322c3ad51a77/d_script.png?classes=w50)

Getting Started - After Match

After Match

Output nodes are flow nodes that specify how the bot should respond. Most importantly, they contain the answer texts, but they also let you specify various other properties.

![outputs](//images.ctfassets.net/2vbtnveccz5s/4XwiScupkz6LErrR7hC4YR/8d1031a93c371a9f646b1a4cd11e05ed/outputs.png?classes=w50)

If you select an output node, various panels on the right side of the window can be used to alter the output nodes' behavior.

## Answer texts

The most common thing to add to an output node is an answer text: a response from your bot in natural language. Answer texts are specified in the 'Answers' panel. You may add several answer texts that are phrased slightly differently. Having multiple variations of an answer text is mostly relevant when you expect that the flow containing the answer might be triggered several times in the same conversation. That way your bot won't sound repetitive if a user runs into the same output node more than once.

![multiple answers](//images.ctfassets.net/2vbtnveccz5s/3325PRuAYEJWXpSkzTtbl6/cd8fc52b66e5b36766862d06872f6204/multiple_answers.png)

If you define more than one answer text, the final text will be used as a fallback, meaning it will be repeated after all the other answer texts in the output have been given once. For the blocks of answer text preceding the fallback, you can specify whether the bot should pick one at random or show them in the order provided. To do this, use the button under the green 'Add' button; this will give you the options to 'Set Order' while selected or order randomly when not selected. You also have an option to select 'Cycle'; this works when 'Set Order' is activated. This will make the Outputs go around in a Cycle, returning to the first answer text again. Otherwise, it will return to the last message in the list.

![2a-buttons](//images.ctfassets.net/2vbtnveccz5s/69JmSyl4shYoPuGcS0ncoc/ac6b245d8e13382b0c6350d6ced1c80d/2a-buttons.png?classes=w50)

### Generate answer variations
Teneo's copilot features allow you to quickly generate new answer variations based on the answer(s) you've written so far. This can be done with the Generate button:

![generate answers](//images.ctfassets.net/2vbtnveccz5s/3gKl7fq05re0AK24GIi0fD/257571565d40c5eab702738e40df840e/generate_answers.png)

!!! In order to enable copilot features, make sure to first [define settings to use Generative AI](/documentation/latest/home/teneo-7.4/teneo-studio#teneo-studio_generative-ai_studio-account-page).

Once new answers have been generated, the flow will look like this:

![new generated answers](//images.ctfassets.net/2vbtnveccz5s/1pfmoUxoChEZbwiOnJgyfG/83f1b15405ea7cfc43f53bef82aba280/new_generated_answers.png)

## Revisitability

Still in the 'Output' node panel, you can specify if an output node can be *revisited* or not in the 'Resume Prompts' section. Revisitability has to do with interruptions, for example situations where your bot has asked a question to the user and the user responds with a request for clarification, switches topic, or simply responds in a way that is not understood. [Click here](/getting-started/handle-interruptions#set-the-output-node-to-revisitable) for a practical example of this.

Let's look at an example:

> **User**: I'd like to order a coffee.  
> **Bot**: Ok, what coffee would you like?  
> *At this point the flow that handles coffee orders is triggered and the bot asks for the coffee preference of the user.*
> 
> **User**: Which coffees do you have?  
> *The user does not answer the bot's question, but asks a different question instead. In other words: the flow that handles coffee orders is **interrupted**.*
> 
> **Bot**: We offer a variety of handcrafted coffee drinks - from espressos to macchiatos to flat whites and more.  
> *The bot finds another flow to answer the users question and...*  
> **Bot**: Let's continue with your order. Which coffee would you like?  
> *...then continues the with the flow that handles coffee orders. To be more specific: the output node that asks for the coffee preference is **revisited**.*
> 
> **User**: A flat white, please.  
> **Bot**: Ok, a flat white will be ready for pickup in 5 minutes.  
> *The flow that handles coffee orders is finished.*

In short: if you want your output node to 'survive' an interruption, you make it *revisitable*. Otherwise, you make it *non-revisitable*.

*   If a flow is interrupted after a __revisitable output node__, your bot will return to that point of the flow after your bot has completed the flow that was triggered by the interruption.
*   If a flow is interrupted after a __non-revisitable output node__, your bot will simply exit your flow at that point and continue with the flow that was triggered by the interruption. You can thus think of non-revisitable output nodes as optional end nodes or exit points. They even have the same appearance as end nodes: they have a purple border.

![3-revisitable](//images.ctfassets.net/2vbtnveccz5s/2ReRv0EeQCAHON0Nk5bVMu/39317d0ce5c26c55b7b279d1c874d64a/3-revisitable.png?classes=w60)

You specify revisitability with a checkbox in the 'Resume Prompts' panel. Here you can also limit how many times you allow the output to be revisited. If the limit is exceeded, the flow is dropped. This way you can avoid making your bot too stubborn.

## Resume prompts

If you add a resume prompt to an output node, that prompt will be given instead of the ordinary answer texts when the node is revisited after an interruption. You add resume prompts in the 'Resume Prompts' panel. More on how this is done can be seen [here](/getting-started/handle-interruptions#add-a-resume-prompt-optional).

## Skip conditions

Skip conditions are used to prevent your bot from asking for information that is already known.

For example, if a user says: *I would like to order one cappuccino please*, you want your bot to ask: *Ok, what coffee would you like?*. But when the user says: *I would like to order one **cappuccino** please*, you want your bot to **skip** the question: *Ok, what coffee would you like?*.

With a skip condition, you can specify that an output node should be skipped (or jumped over) if a particular condition is true.

You add skip conditions to your output node under its 'Skip conditions' panel. There you specify the condition *when* it should be skipped (e.g. if the variable for flavor has already been set), and *where* it should skip to, i.e. which transition to follow after the output has been skipped.

The page [Skip Conditions](/getting-started/skip-conditions) shows how to build a flow that can handle coffee orders and it uses skip conditions to avoid redundant questions.

## Output parameters

Output parameters can be used to provide your app with information that has no place in the regular answer text. For example, suppose a bot can provide weather information in a mobile app. The answer text of an output might contain a humanlike description of the weather (*It's quite sunny in Amsterdam at the moment, make sure to wear sunscreen!*). But in addition to that, the app could display a widget with more detailed weather info. The information that needs to be displayed in the widget could be passed on as JSON in an output parameter. Each output node can have as many output parameters as you like, each parameter needs to have a name and a String as value.

You add output parameter to your output node under its 'Output Parameters' panel shown [here](/article/build/scripting/how-to/populate-output-parameters).

## URLs and Emotions

Each output node has a separate URL field. This URL is included as a separate field in your bot's response. The frontend application can use this field to automatically open a webpage, for example. The same is true for 'emotions': each answer text can have an emotion associated with it. This emotion is included as a separate field in your bot's response and can for example be used by frontends that display avatars.

The emotions can be found and added in 'Globals'.

![Output-emotion](//images.ctfassets.net/2vbtnveccz5s/S2BsjtZsou8joPuSH3KOh/7438468cf878edf637b9514f0cff617a/Output-emotion.PNG)

!!! For more technical details on how applications can connect to your bot and Teneo's response format, please refer to [Connect to your bot](/article/deploy).

Build - Outputs

Outputs

Language objects are building blocks for [language conditions](/studio/language-understanding/concepts/language-conditions). They capture words, synonyms, or various ways of expressing the same (partial) intent. They make it possible to efficiently write and re-use conditions.

A closer look at language objects reveals that while they are used in language conditions, they also contain language conditions themselves. Moreover, language objects often use other language objects in their conditions:

![language objects](//images.ctfassets.net/2vbtnveccz5s/hDisRbjXPICSxrac2KRUw/e6f008dbba3da1e85205ae703ee1477f/language_objects.png)

All language objects together form a hierarchical structure, where word-level language objects are at the bottom, and various kinds of lists, synonyms, and phrases are at the top.  
You can use both the language objects of the pre-built [lexical resources](/studio/language-understanding/concepts/lexical-resources) that you have linked to your solution, and any language object that you and your team created in your solution.

The main components of a language object are:

*   the name
*   the language condition

We will have a closer look at both of these components in the following.

## Names and types of language objects

The name of a language object is always written in upper case. When you use a language object in a condition, you add a __%__ sign before its name.

The language objects that come with the pre-built language resources follow a naming convention. This makes it possible to get a feel for what they cover already from their names. For instance, a name that ends in __.SYN__ covers a set of synonyms, and a name that ends in __.LIST__ captures a list of some kind, e.g. a list of different colors or car brands.

When Teneo generates language conditions from examples (with the 'NLU Generator' button) it only considers language objects that follow the naming convention (and are of certain types, as indicated in the table below). Thus you should make sure to name your language objects properly if you'd like them to be part of the automatically generated conditions.

!!! If you want to use DOG.NN.SYN as a condition you would need to write __%DOG.NN.SYN__

The most important language object types are:

| Suffix | Type | Example Name | Example Condition | Used by 'NLU Generation' |
| --- | --- | --- | --- | --- |
| LEX | **Lexical entry**: is the smallest building block from which more complex language objects are built. Covers different inflections of a word, but also spelling and regional variations. | DOG.NN.LEX | dog / dog's / dogs / dogs' | yes |
| SYN | **Synonyms**: groups language objects with similar meaning. | DOG.NN.SYN | %DOG.NN.LEX / %HOUND.NN.LEX / %MUTT.NN.LEX / %POOCH.NN.LEX / (...) | yes |
| ENTITY | **Entities** are collections of one or more words that all have some characteristic in common. | COFFEES_SERVED.ENTITIY | Click [here](/getting-started/create-custom-entities#create-a-coffees-served-entity) for details | yes |
| PHR | **Phrases**: groups various ways of expressing the same phrase or partial intent. | IS_BROKEN.PHR | ((%BE.VB?PRESENT.LEX / %SEEM.VB.SYN)>> %BROKEN.ADJV.SYN ) / (...) | yes |
| LIST | **List**: lists related concepts, such as colors or country names. A list often contains other lists. | HERBS.LIST | %BASIL.NN.LEX/ %CILANTRO.NN.LEX/ %CORIANDER.NN.LEX / (...) | no |

Language objects may also contain an infix signalling their part of speech. A more extensive table of the language object types, and part of speech tags used, can be found [here](/studio/reference/language-object-reference).

## Language Condition

The [language condition](/studio/language-understanding/concepts/language-conditions) in a language object describes patterns that need to be present in a user input for the condition to be fulfilled. They are expressed in Teneo's [TLML Syntax](/studio/reference/condition-syntax).


Build - Language objects

Language objects

Entities are a special kind of [language object](/studio/language-understanding/concepts/language-objects?target=_blank). They cover words that have some characteristics in common. Each entity consists of one or more entries, which denote what the entity is matching and optionally also which features are assigned to this entry.

For your bot to understand what the user said, some words of the user's utterance are more **important** than others. Typical examples for such important words include so-called **named entities** like cities or product names.  
One way of catching these is using *entities*.

## What is an entity?

Each entity covers a collection of one or more words called 'entries', which all have some characteristic in common. For example, these all denote cities in the Netherlands:

![first picture](//images.ctfassets.net/2vbtnveccz5s/6QTMxyGIU0gTm3nYtrxkeL/0dfbe48ec2126398ebaeda37c3d2b0a0/first_picture.PNG)

To enhance natural understanding, the entries can have variables carrying additional information about each entry. For example, different names may denote the same city, like *"Den Haag"* and *"The Hague"*. With variables, it is possible to map these different variants to the same city name. Another example is the code of the nearest airport, which is useful to have in-flight booking scenarios.

![secondpicture](//images.ctfassets.net/2vbtnveccz5s/7g9YRHejBUav9pJzh7Rxsg/336cca250547f963dfa34f8ba6f72459/secondpicture.PNG)

!!! In the entity examples above, all entries are strings. It is also possible to have entities added as scripts. Note that entries may also consist of other entities or [language objects](/studio/language-understanding/concepts/language-objects).

## How to use entities

In order to use the entity covering the cities of the Netherlands in your flow, simply add `%CITIES_NETHERLANDS.ENTITY` to your [language condition](/studio/language-understanding/concepts/language-conditions).  
The variables __sCity__ and __sAirportCode__ can be accessed using [attached scripts](/studio/language-understanding/concepts/attached-scripts) and [data actions](/getting-started/data-actions).

## Prebuilt entities

Teneo comes with a collection of pre-built entities that are ready to be used. Some of them have been machine-learned, like geographical entities like cities or addresses, while others have been hand-crafted, like a list of colors. A full list of available entities can be found [here](/documentation/latest/reference/pre-built-knowledge/entities).

## Create your own entities

Besides the pre-built entities, you may also create your own. The option to use generative AI with Teneo's copilot features makes this process easy. See [Introduction to Entities](/getting-started/create-custom-entities) for guidance. For an example of how to use them in a flow, see [Extract Entities](/getting-started/build-a-slot-filling-flow).

## Entries

Entities allow for four different kinds of entries:

1.  a word,
2.  a sequence of words,
3.  a different entity,
4.  a different language object.

Internally, a sequence of words will be transformed into Teneo's [condition syntax](/studio/reference/condition-syntax). For example, if the two words "Chai latte" are entered into the entry field of an entity, they will be interpreted as __Chai>>latte__ which means that the word "Chai" is directly followed by the word "latte" without any intervening word allowed in between them. However, this holds only for sequences of strings. For any other combination of entries, e.g. sequences containing entities or language objects this is not possible. If you want to add such a sequence (for example __HOT.ADJ.LEX WATER.NN.LEX__) to an entity you will have to create a new language object (here: __HOT_WATER.ADJNN.MUL__) that contains the sequence of these two language objects in its language condition. This multiword language object can then be added to be an entry of the entity __BEVERAGES_SERVED.ENTITY__.

## Entity variables

Entity variables can be used to add properties to the different entries of an entity. There are two variable types: strings and scripts. The variable type can be determined using the toggle below the variable name. An example is given below. The customized entity __BEVERAGES_SERVED.ENTITY__ contains all kinds of beverages served at Longberry Baristas. Its consist of

*   four entries: two other entities (__COFFEES_SERVED.ENTITY__, __TEAS_SERVED.ENTITY__), a language object (__WATER.NN.LEX__) and a set of words ("Chai Latte"),
*   a string variable "temperature",
*   a script variable "beverageType", which is retrieved from the entity variables __coffeeType__ and __teaType__ that are defined in the nested entities __COFFEES_SERVED.ENTITY__ and __TEAS_SERVED.ENTITY__. For 'water' and 'chai latte' the value of the "beverageType" is given directly as strings.

![entity variables](//images.ctfassets.net/2vbtnveccz5s/5hoYmiOpzwuwJMGzHWyTe2/f97a70b71a63dac7f6159da9fddb416b/entity_variables.png?classes=w80)

!!! As you can see, a string variable can only contain strings, whereas a script variable can contain script expressions or strings. However, if you add strings to a script variable, make sure to add quotes around them.

## Accessing entity variables

In the example below we [attached a propagation script](/studio/language-understanding/concepts/attached-scripts#propagation-scripts) to an entity in a listener condition. The flow variable __orderedBeverage__ is assigned __lob.beverageType__. This __lob__ is a special variable which points to the entity (or, more generally speaking the language object, hence __lob__) to which the script has been attached to, __BEVERAGES_SERVED.ENTITY__, and retrieves the value of the entity's variable __beverageType__.

![accessing entity variables 2](//images.ctfassets.net/2vbtnveccz5s/1GQxQArmvXc3vK0x4UwStf/bd503a5f98c4d3d153d6d7381be715c6/accessing_entity_variables_2.png?classes=w50)

### Value propagation

So for example, if the user input is 'I want an Americano', then the value 'americano' will be assigned to the flow variable __orderedBeverage__.

What happens is the following:

1.  All entries of __BEVERAGES_SERVED.ENTITY__ are searched through to match the user input.
2.  A match is found in the language object __AMERICANO.NN.LEX__ of the nested entity __COFFEES_SERVED.ENTITY__.
3.  The value "americano" of the entity variable __coffeeType__ is propagated up to the entity variable __beverageType__.
4.  The value of the variable __beverageType__ is accessed via the propagation script in the listener condition and assigned to the flow variable __orderedCoffeeType__.

![value propagation 3](//images.ctfassets.net/2vbtnveccz5s/2wyTVIWJCveiB8lbo4DVQj/4c18e8558a2022ad523c80b59e6463ec/value_propagation_3.png)

Build - Entities

Entities

Transitions connect flow nodes with each other. They determine the paths a dialogue can follow. If there are multiple transitions leaving a node, all transitions are tested in a certain order and the first one whose condition is satisfied is chosen.

![1-transitions in flow](//images.ctfassets.net/2vbtnveccz5s/3ASHhg5MdabOilr2PAM6lq/d2c03c0b04ef7b17fb150d62fa140508/1-transitions_in_flow.png?classes=w60)

## New input or not?

Some transitions wait for a user input, while others do not. You specify whether a transition should wait for a new input or not with a checkbox in the 'Triggering' section.

![2-get input](//images.ctfassets.net/2vbtnveccz5s/3SrhtJk8Ysd4nIaPCOUGab/043a56b0fa5677ce2738826be65f5cb4/2-get_input.png?classes=w80)

In case a transition has the __Get input before continuing__ checkbox selected, the flow processing halts until the user has provided an input. Usually, such transitions are placed after output nodes in which the bot asked a question.

## Match Intent or not?
Just like [triggers](/studio/flows/concepts/triggers#syntax-triggers), transitions can also have a Match requirement to evaluate if the input of a user meets the criteria to follow a transition. You can either hand-craft the Match yourself or let Teneo automatically create it for you from a set of test data, after which you can edit the Match.

Let's say that you want to capture extras together with a coffee order:

![3-coffee extras](//images.ctfassets.net/2vbtnveccz5s/7L6OrylXPhF6fjrmTWPRlE/49ccc37bb0fe654a5013fd4ef9267297/3-coffee_extras.png?classes=w60)

The TLML Syntax for the 'Milk and sugar' branch may look like this:

![4-tlml syntax](//images.ctfassets.net/2vbtnveccz5s/10JtjeH5BRNswEQl24CxKO/59872ff9a705613901b816be91e79d21/4-tlml_syntax.png?classes=w40)

For syntax conditions in transitions, it is usually enough to focus on the crucial content-bearing keywords. This way, less important words that might exist in the user's input are ignored.

!!! You can also use **Groovy code** in the condition field. The code should be enclosed in curly brackets, e.g. __{userAge > 12}__ (which requires the value of the variable __userAge__ to be greater than 12 to determine if the user may drink coffee). Language conditions that consist of Groovy code are often used in transitions that continue without user input.__

## Order

If multiple transitions have the same node as their starting point, you specify the order in which they (or rather, their conditions) should be tested. The order is displayed in the flow graph as a number on the transition and is displayed from left to right, with the highest order placed on the left and the lowest on the right. You can change the order in the 'Triggering' panel.

![5-ordering](//images.ctfassets.net/2vbtnveccz5s/6gFAN5jjArQClOOBSk1RkZ/07ac233c10ea70232e9f212c43ef6dc0/5-ordering.png?classes=w60)

When setting up the ordering of the transitions, make sure that the more specific conditions are tested first and the more general ones last. Otherwise, the more specific ones will never be chosen.

## Repeatability

You can specify whether a transition should be considered just once per session, or always. This is useful when you want the behavior of a flow (or a point of flow) to be different depending on how many times the user visits it. You specify whether a node is revisitable with a checkbox in the 'Resume Prompts' panel:

![8-repeatability](//images.ctfassets.net/2vbtnveccz5s/4ajTKme1Q9VQrjaWVkcyHo/03562b421b05de6dfbb010a392815540/8-repeatability.png)

Build - Transitions

Transitions

Variables are important when building bots. Not least, your bot's memory will rely on what is stored in variables. Global variables in Teneo are accessible from all flows, script nodes in flows, listeners and most [script events](/article/build/scripting/concepts/scripts) in your solution. In that way, they differ from [flow variables](/article/build/flows/concepts/variables#flow-variable), which only exist during the processing of a flow, and will be forgotten as soon as a flow is dropped from the [flow stack](/studio/conversations/concepts/flow-stack).

## Global variable

### Create a global variable

You can create global variables in the main solution window. Open the 'Solution' tab and select 'Globals'. Then select 'Variables' at the top, and click 'Add' in the upper right corner. Give the variable a name, and assign it with a default value.

![1-global vars](//images.ctfassets.net/2vbtnveccz5s/NmW2UMgbu7ioD6cWxipSh/1b748b2394faecf6568037a0bc2b5248/1-global_vars.PNG)

### Lifespan

By default, the value of a global variable lives for the entire session, or until it's reset. You can, however, make a global variable forget its value after a specified number of turns. The variable will then be cleared and get back its default value. In Teneo this is called *'setting the lifespan'* of a variable. A [common use case](/studio/conversations/how-to/share-information-between-flows) is to remember something the user says in one flow, so that it can be used in another flow.

If you have a global variable called __topic__, you would set its lifespan like so:

    `_.setSessVarLifespan('topic', 2)` 

You would typically set the value of the variable at the end of a flow and at the same time set its lifespan. In this example, the lifespan is set to two turns, but you are free to choose whatever value you see fit. Note, however, that the lifespan includes the request/input that is currently being processed. Each subsequent request (or input or turn) will consume one of the lifespans and when the lifespan reaches 0, __topic__ will be reset to the value that was used when it was initialized. However, any flow can overwrite the value of the global variable at any time and give it a new lifespan.

## Flow Variable

Flow variables allow your bot to remember details during the processing of a flow. Anything you store in a flow variable will be forgotten once the flow has finished processing. If you want to [share information between flows](/studio/conversations/how-to/share-information-between-flows), you have to use [global variables](/article/build/flows/concepts/variables#global-variable) instead.

### Create a Flow Variable

To create a flow variable, open a flow in 'Edit' mode, go to the 'FLOW' tab and select 'Variables'. Click on 'Add' in the upper right corner, and provide a name and a default value. In the example below, we have two variables, __flavor__ and __size__, which both have an empty string __""__ as the default value.

![flow variable](//images.ctfassets.net/2vbtnveccz5s/poo9ta8hju3rGrKvYIUsl/67d39edfcb42d4533d994a62bb9bae26/flow_variable.PNG)

!!! In Teneo, variables may be of any type that Groovy (and Java) supports, including strings, booleans, maps, lists, and custom objects. It's possible to populate and edit a variable in your flow, you can populate a flow variable using a script, or you can store the results of an integration or a Sub-Flow in a variable.

## Local variables
Local variables are only available in the script node (or script event) in which you created them. You must define or specify the type of the local variable like so:  `def name = "Guillaume"`. You can see an example of a script with local variables here: [How to add a script to your flow](/studio/flows/how-to/add-a-script-to-your-flow).

Build - Variables

Variables

Sub-Flows are often used for re-usable pieces of logic. For example, you might have a solution in which multiple flows need to ask for a date of birth. In that case, one single Sub-Flow that asks for the date of birth can be used. This Sub-Flow can then be called by any flow that needs the user's date of birth.

Unlike regular flows, Sub-Flows are not triggered by a user input. In fact, Sub-Flows do not have triggers at all. Sub-Flows can only be activated when linked to from other flows.

## Linking to a Sub-Flow

Once the Sub-Flow has finished processing, execution will be handed back to the parent flow. One flow can link to multiple Sub-Flows, which will behave as if they were part of the parent flow. Sub-Flows can also link to other Sub-Flows. When linking to a Sub-Flow you can specify which variables can be transferred back and forth. If an output in the Sub-Flow uses a revisitability limit and that limit is exceeded, the Sub-Flow and all calling flows are dropped.

![linking subflow](//images.ctfassets.net/2vbtnveccz5s/7xL31qdu9YLeFxjVqpYVd9/8b5ccb6fc7f3303d943c038429879af8/linking_subflow.png)

## Creating a Sub-Flow

Sub-Flows are created as easily as regular flows by clicking on the arrow below 'Flows' and selecting 'Sub-Flows'.

![1-create sub flow](//images.ctfassets.net/2vbtnveccz5s/3AW3QO6baF52Cq5hG1g4RU/d7689331c3124eceb5cd77aebc4d61bf/1-create_sub_flow.png)

It is also possible to turn a regular flow into a Sub-Flow. To do that, simply click on the 'Sub-Flow' icon in the 'Flow Entry' group of the ribbon when editing a flow. This will remove the trigger and turn it into a Sub-Flow entry point.

![2-turn into sub flow](//images.ctfassets.net/2vbtnveccz5s/46uNAZEVDsZJS0fE11RGQY/e6564b45d1e7b354a2085e7ad707cda7/2-turn_into_sub_flow.png)

Once a Sub-Flow has been created, it will look something like this:

![3-sub flow entry point](//images.ctfassets.net/2vbtnveccz5s/7v7wXiggaD5muccKabHJlf/1020ae142c631dd559091b2b55a65577/3-sub_flow_entry_point.png)

## Linking to a Sub-Flow

Sub-Flows are ideal for reusable logic. In this example, we have created a Sub-Flow to get the user's email address, which could be needed for various use cases:

![4-get email address flow](//images.ctfassets.net/2vbtnveccz5s/t2cxWxtCIDYrsqNqfeAi9/ca5331431b3bdc4cf894fde686f1e85a/4-get_email_address_flow.png)

We can then call this Sub-Flow from other flows to get the user's email whenever necessary. In the example below, we used this Sub-Flow in a Flow where we add the user to a mailing list.

![5-call to sub flow](//images.ctfassets.net/2vbtnveccz5s/26dzfgfCIkpPtkwIsYRxd4/fa58262850869f033f4f63e731dfb582/5-call_to_sub_flow.png)

When calling a Sub-Flow, we can send and receive values to and from the Sub-Flow. In this case, we do not send any values, but we receive one (i.e. the email address).

Build - Sub-Flows

Sub-Flows

Junctions help you to model the layout and logic of your flow. Multiple transitions can point to the same junction, or a junction can be the starting point of multiple transitions.

![1-junction](//images.ctfassets.net/2vbtnveccz5s/XHnK52gdRISpuxKdkSZgk/ab5c0d30fbe054cffb62e4a20112790b/1-junction.png?classes=w30)

Junctions themselves don't do anything. They don't execute scripts, nor do they display an output. They just offer an easy way to model your flow. By following the rules below you will learn how to get the most out of junctions.

## When do we need junctions?
Here we will describe some common cases where junctions are used in flows.

### Branching at the beginning of a flow
If you want to branch immediately after a flow trigger you can do this using a junction. This might be necessary if you have different responses for the channels your bot uses, or for different customer types, or for specialized cases of the user input. In this exercise we show you how to [branch at the beginning of a flow](/studio/flows/how-to/branch-at-the-beginning-of-a-flow).

When you add a branch at the beginning of a flow it looks something like this:

![junctions-flow](//images.ctfassets.net/2vbtnveccz5s/GNCTtF2tccogow2eAKqXu/d249d6434a7f2859c62772871c33b40a/junctions-flow.png?classes=w60)

###  When transitions share part of a condition
In this example the transitions following the junction represent special cases of the main case that leads to the junction.

![most-cases-europe](//images.ctfassets.net/2vbtnveccz5s/4U6edvSUPAQXoCf4t8AUj6/5c36651f86470c1bd213de039d948c50/most-cases-europe.png)

## When can we avoid junctions?
Keep in mind that you can branch directly from an output node without using a junction. Adding junctions in such cases can make your flow harder to manage and also introduce unwanted errors. When adding a simple branch, don't use a junction.

![4-avoid junctions](//images.ctfassets.net/2vbtnveccz5s/51IXeKHqmnm7377IkylaX2/fa65b44f69fcc207a28352c6da6538cf/4-avoid_junctions.png)

Have a look at the [transitions](/studio/flows/concepts/transitions#conditional-or-not) page for another example of correct branching from an output node.

## How do we use junctions correctly?
You can add logical branches to your flows using junction nodes. These branches (transitions) can be assigned a language or script condition, and can also be set to unconditional. Here we describe some basic guidelines to help you use junctions in the best way possible. 

### Tip 1: Incoming transitions that 'get input' must include a Match
Transitions connecting an output to a junction should be set to 'Get input before continuing' and include 'Match'. If a transition has a 'Match' it could use a [language condition](/studio/language-understanding/concepts/language-conditions).

![european-countries-new](//images.ctfassets.net/2vbtnveccz5s/5gJ8tzOj4DoyTlOEycXHtM/32548ea1cdea1aac18e860424d84edb3/european-countries-new.png)

### Tip 2: Leaving transitions must not 'get input'
Make sure the transitions leaving a junction do not use the option 'Get input before continuing'. As junctions typically come after an input is given, doing this will force the user to repeat their input, without being prompted to do it. Causing a risk for the flow being stuck. Toggle this option with the checkbox in the Triggering section of the configuration panel. You can open the configuration panel by clicking on the transition. 

### Tip 3: Use a fallback transition
When multiple transitions leave a junction, use the last transition as a fallback, and make sure it does not have a 'User Intent' in place. In this example, the first three transitions are set to 'Match', and the fourth one, which serves as the fallback transition, is not. None of the four transitions are set to 'Get input before continuing'.

![6-fallback](//images.ctfassets.net/2vbtnveccz5s/1Us2BrUOQVjWjTKiHTwzvn/701bcba3a43309c9b8d359d0bc93df3e/6-fallback.png)

Theory/Core Concepts

New input or not?

Match Intent or not?

Order

Repeatability

Next page