## Objectives

In this section you will:

- Learn more about the role of Flows in the conversation design
- Learn about the main nodes of flow 
- Learn what a Trigger is and how they related to flows
- Learn how to make a flow interactive

Objectives - Design your Conversation Logic in Flows  - Fundamentals 

Objectives

## Flows
Dialogues in Teneo are handled by Flows. Flows are visual objects that contain all the necessary logic to resolve a user's question or intent. Depending on the user's intent, the flow may vary in complexity. You can add as many flows to your solution as you want. Together, the flows allow the user to have a conversation about different topics.

Flows can be simple (e.g. to answer the question "What kind of coffee do you have?") or complex (for example, a flow that helps the user book a flight), but they always represent some kind of predefined conversational pattern.



Flows in Teneo are represented graphically. At the top of the flow, we find the trigger. This is where we define what kinds of inputs should activate the flow. This can be done in various ways, including by creating machine-learned classes or by defining linguistic rules.

Simple flows just contain a trigger that recognizes the user's intent and an output that contains the answer.

![intent-output-fixed](//images.ctfassets.net/2vbtnveccz5s/3R7dzQRxy9O7FvHZGGksek/10c33c141370b974eac33a4a999e0373/intent-output-fixed.png?classes=w40)

More complex flows may contain many more elements like junctions & transitions, different outputs, links to other flows, etc.

![build-complaint](//images.ctfassets.net/2vbtnveccz5s/kdWLUbop3m0jNblYAM3Bt/7dcb0742aca042803c8fb0c9bb30587a/build-complaint.png?classes=w50)

Introduction to Flows - Learning Journey

Introduction to flows

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

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

Activate your flow with intent triggers

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

Add a response text, or two

Sometimes your bot will need some additional information from the user before it can provide a final answer. On this page, you will learn how to branch after an output prompt and take different paths depending on the user response. These paths in Teneo are known as transitions and are used to tie flow nodes together.

We'll use the following example, where the bot provides information about the coffee mug to the user, and then the bot needs a confirmation from the user before it proceeds to reserve a coffee mug:

> **User:** I want to buy a coffee mug.  
> **Bot:** The official Longberry Baristas coffee mug is only available for purchase in our store. Would you like me to reserve a mug for you?
> 
> **User:** Yes.  
> **Bot:** I have reserved a Longberry Baristas coffee mug for you.

or

> **User:** I want to buy a coffee mug.  
> **Bot:** The official Longberry Baristas coffee mug is only available for purchase in our store. Would you like me to reserve a mug for you?
> 
> **User:** No.  
> **Bot:** Ok, I will not reserve a coffee mug for you.

To achieve this we will do the following:

*   Create a new flow.
*   Populate a trigger with example inputs and generate a Match.
*   Add an output response in the form of a question.
*   Create a 'yes' transition if the user replies with 'yes'.
*   Add output response for the 'yes' scenario.
*   Create a 'no' transition if the user replies with 'no', and then add answer text for the 'no' scenario.
*   Save and test the flow.

This is what our flow will look like when it is completed:
![final flow](//images.ctfassets.net/2vbtnveccz5s/5oJ2Qu3UnIwkQT0b5qDi1L/1f2a149eb235aa367f318542968f0ce9/final_flow.png)

This page will only cover the communication with the user. To actually reserve a coffee mug, we would have to integrate with a service; we will leave that part out for now.

## Create the basic flow and populate the trigger

The first steps are to create a new flow and populate the trigger with relevant training examples. Start by doing the following: 

1.  Select the 'Flows' folder and create a new flow by pressing the 'Flow' button.
2.  Once the flow has been created a new window will open; enter the flow name `User wants to buy a coffee mug` into the name field.
3.  Press the back button in the top left corner and select the trigger to open the trigger configuration panel.
4.  Give the trigger the name `I want to buy a mug`
5.  Add the positive learning intents below either one by one, or paste them all at once by clicking where it says, 'No Positive Intents' and use the shortcut __Ctrl+V__ (alternatively, you can also right-click and choose __Paste__).

```example-inputs
Do you have branded mugs for sale?
Can I buy a mug please?
Do you sell mugs?
Can I purchase a mug?
Purchase coffee mug
I want to buy a mug
Do you have coffee mugs for sale?
I would like to purchase a coffee mug
I want to buy your coffee mug
Do you sell longberry barista mugs? 
I want to have a longberry barista branded mug
I want to buy a mug!
```
6.  Now we need to add a Match. Click on the 'Generate' button under 'Match' section, this will automatically generate the best Match requirement based on the User Intents.

![1-create flow](//videos.ctfassets.net/2vbtnveccz5s/12JcYdS5vLlN1pvVWk9gNt/235fdf6d9574dccecf5c563c6985f5a0/1-create_flow.mp4)

## Add answer texts to the output

Now we will populate the output node with answer texts. In this case, the output node will be used to give the user information about the Longberry Barista coffee mug and then ask a question, rather than just give a definitive answer.

1.  Select the output node to open the output configuration panel.
2.  Add an output name and enter a name like `Ask the user if they want to reserve a mug for in-store purchase`.
3.  Add the following answers to the output node (use the __Add__ button to add the individual answers):
*   `The official Longberry Baristas coffee mug is only available for purchase in our store. Would you like me to reserve a mug for you?`
*   `Right now you can only buy our coffee mug physically in our store. Do you want me to reserve one for you?`
*   `Our coffee mug is only available for purchase in our store. Shall I reserve one for you?`

![2-add output](//videos.ctfassets.net/2vbtnveccz5s/546idzGDSB86b5VtemLd2y/2220d8f3e90633e7b5a7a28336a0abd5/2-add_output.mp4)

Output nodes can contain multiple answer variations to make the conversation more dynamic. Teneo allows you to either randomly choose an answer and return it to the user, or to set order for the outputs to be returned.

```infobox
## A brief explanation of transitions

Before we start extending our flow with transitions, it might be a good idea to quickly go over the concept of transitions. Transitions link different flow nodes together and determine the paths a dialogue can follow within a flow.

By default, all transactions will create transitions that contain a User Intent. These transactions require the addition of one or more Matches. Transitions that have a User Intent but no assigned Match requirements will get a yellow 'TODO' label as a reminder. When the User Intent is enabled, the most recent user input must match the set Match to continue down the transition. You can remove the User Intent option for a transition. This means that the transition will allow any user input to continue down the transition as it has no Match requirements. Transitions are also ordered, which tells Teneo in which order to test the Match on conditional transitions.

Transitions are by default set to ‘Get input before continuing', which is also displayed in the flow graph. This means that the flow processing will stop and wait for the user to provide new input. If the user input fits the transition's Match requirement, the flow processing will resume along with the transition. If the transition is not set to wait for user input before continuing, the flow processing will not stop and wait for new user input. If this is the case, the most recent user input will be tested against the Match requirement.

![brief explanation](//images.ctfassets.net/2vbtnveccz5s/2xffTXp9v7XwzwqSBOFhC4/0cfe5efb4026b55a2e633b2bd52e954e/brief_explanation.png)

```

## Add two transitions

We have now reached the point in the flow where we expect the user is going to say either 'yes' or 'no'. Depending on what is said, the bot should react differently. Let us start with adding these transition.

1. Located under the output node 'Ask the user if they want to reserve a mug for in-store purchase', click on the Plus icon, followed up with 'Fork To' and 'Multiple complete transactions'.
You will now have the option to select the number of times the output should be forked.
2. Enter '2' and click on confirm.
Notice that two new paths are shown for the user to take. These will now be edited to cover the 'yes' and 'no' options.

!!! Do you see that there are numbers on the transitions (1 and 2 respectively)? These numbers represent the order in which Teneo will test the conditions. You can adjust this order by having the transition selected, then use the arrows found under the two checkboxes 'Get input before continuing' and 'Match' to increase or decrease the order of the selected transition.

So far, you have created two flows in your solution, each containing one trigger with a Class Match. But in the next section, you will get to add a Language Object-based Match to a transition.

![3-fork to transactions](//videos.ctfassets.net/2vbtnveccz5s/4kQ6tz3yEkGFx4rH9HpWWR/d06e156929e61a2cbffdd829e03ec381/3-fork_to_transactions.mp4)

### Add a Language Object Match

Now we need to make sure that one of the paths only matches (the line that connects two output nodes) when the user says ‘yes’. To achieve this, we need to add a new type of Match requirement, namely a [language condition](/studio/language-understanding/concepts/language-conditions). Simply put, language conditions check if a user input matches a certain pattern. They can be generated from a set of examples or you can specify them directly. Let's generate one from a set of example inputs.

1.  Open the transition configuration panel by selecting the transition labelled '1'.
2.  Give the transition the name `User says 'Yes'`. This increases the readability of the flow and makes debugging easier.
3.  In the examples panel, paste the following examples:
```example-inputs
Yes
Indeed
Yep
```
4.  Finally, click on the 'Generate' button under 'Match' section, this will automatically generate the best Match requirement based on the example specification.

After a few seconds, the match requirement field will get the value `(%YES.PHR)`. This is the 'Match' for 'Language Objects' that was generated. The language condition uses a 'language object' called YES.PHR, which recognizes various phrases (hence the suffix .PHR) that mean 'yes', like 'by all means', 'absolutely' and 'yup'. This perfectly covers our need for this transition. Note that there is a lot more you can do with language conditions, but that will be covered later.

The condition used as a Match in this example is based on the User Intents, and unlike class, there is no ‘condition manager’. This means that all conditions are managed on the node or transition itself.

![4-add LO match](//videos.ctfassets.net/2vbtnveccz5s/65neZaUFB4W7DdFbZwZ87P/16e288de66e63e4507a5f26a96296f31/4-add_LO_match.mp4)

So far, we have only added one Match per trigger and transition. We have only explored two different types of Matches, Class, and Language Objects. However, triggers and transitions can contain one or more match requirements. It is also possible to mix the Match requirement types depending on what the use-case requires, this is however not going to be covered on this page. You can read more about it [here](/studio/flows/concepts/triggers#match-requirements).

### Add an answer text

The last step to complete the 'yes' branch is to specify how your bot should respond when the user says 'yes'. The output node below the 'User says Yes' should be selected: 

1.  Give the output a descriptive name like: `I have reserved a coffee mug for you`.
2.  Finally, add the answer text: `I have reserved a Longberry Baristas coffee mug for you.`

![5-add yes path answer](//videos.ctfassets.net/2vbtnveccz5s/1AEnQtr3Rd7GrlZnsfDLfN/d864da46217be9c01708d3881e7cd8ad/5-add_yes_path_answer.mp4)

## Create the path for the user saying 'no'

Now, we will specify what should happen when the user says 'no'. We'll follow the same steps as when adding the first branch:

1.  Select the transition labelled '2'.
2.  Give the transition the name `User says 'No'`.
3.  Add a few example inputs in the examples panel:
```example-inputs
No
Never
Nope
```
4. Finally, click on the 'Generate' button under 'Match' section, this will automatically generate the best Match requirement based on the example specification.

![6-add no path](//videos.ctfassets.net/2vbtnveccz5s/12LaZKGhZEpqauGIoPP2oM/cb91669d681e2af1aa988e56071cf423/6-add_no_path.mp4)

### Add an answer text for 'no'

Almost there! Now we need to make sure that the reply is recognized and taken care by the flow.

1. Select the Output node below the transition.
2. Give it the name: `Ok, I will not reserve a coffee mug for you`.
3. We can reuse the name of the output node as our answer text.

Finally, save your flow by clicking 'Save' in the top left or use the shortcut __Ctrl+S__.  

![7-add no answer](//videos.ctfassets.net/2vbtnveccz5s/6j4kKdhktZdfWaU3Ghoo1y/868d4bc77f622d7bed92e6d71c938675/7-add_no_answer.mp4)

## Try it out!

That's it! If you would like to test the flow from within Studio, minimize or close the flow, if the 'Tryout' window is not open, you can reopen it panel in the 'Solutions' window and have a go.  

![8-tryout](//videos.ctfassets.net/2vbtnveccz5s/2X7NmxRSRwI3RxbCH7XYg6/b295ebc28b43958dd92ac6af2a7e7d43/8-tryout.mp4)

!!! Notice the __Flow Updated message?__ The Tryout panel is also used for the bot to communicate with you. When something is updated or wrong the Tryout will print a message for you.

## Summary

You've just created your first interactive flow and used the following components:

*   **Match**, which are used to set criteria that the user's input must match.
*   **Multiple answer variation**, used to make the bot's responses more dynamic.
*   **Language condition**, which you can use to ensure that the user input matches a certain pattern.
*   **Transitions**, which determine the path your dialogue should take.

## Test yourself

Try to add one more branch, but this time for if the user answers with an answer that does not meet the match requirements of the __Yes__ or __No__ transitions. Make sure to test your flow in Tryout!


Transitions

Create an interactive flow

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)

Design your Conversation Logic in Flows

Flows

Next page