Hero - Build your bot

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)

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

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.

![1-output](//images.ctfassets.net/2vbtnveccz5s/28ewwsZWspsMi0kzUlNDHT/b4a524701082b0223fb08a6728dd98ff/1-output.png?classes=w80)

## 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 edit view in the output. 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.

![2-multiple-outputs](//images.ctfassets.net/2vbtnveccz5s/72vyRtLx9TjiLAAc7SxClX/ea990530040fa776bff4537067d5ae53/2-multiple-outputs.png?classes=w60)

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. 


Studio Web - Build - Outputs

Outputs

Analyze your bot

Analyze Log Data

Analyzing sessions

Augmenters

Extract values with Augmenters

Metadata

Running custom queries

Counting coffees with Metadata

Reference

Teneo Query Language Cookbook

Teneo Query Language Reference Guide

Teneo Query Language Syntax Overview

Teneo Query Language

Data hierarchy

Event

Property

Session

Transaction

How to

Explore session statistics

Find stuck flows

Generate session logs

Locate and view a session

Make use of skip constraints

Make use of sub queries

Query variables

Troubleshoot the Safetynet

Use relative dates in queries

Query Syntax

Command

Constraint

Meta-parameter

Selection

Transformer

Build your bot

Bot design

Best practices

Data footprint

Encrypting user data in sessions

Flow checklist

Plan your bot

Starting a new Teneo project

Writing good answers

Writing good examples

Conversations

Concepts

Context restrictions

Flow stack

Greeting message

Listeners

Safetynet

Trigger Ordering

Create a custom order group

Handle ambiguous inputs

Make your bot pro-active

Share information between flows

Use listeners

Flows

Bulk Import

Entities

Junctions

Sub-Flows

Transitions

Intent triggers

Variables

Add a script to your flow

Branch at the beginning of a flow

Use TLML Syntax Match

Use a Sub-Flow

Use Bulk Import

Language Understanding

Annotations

Attached scripts

Language conditions

Language objects

Languages

Lexical resources

Libraries

Linguistic Modeling Language

Localization

Match requirements

Used words

Combine Match requirements

Create a solution in your language

Create your own language objects

Find language objects and entities

Localize a bot

Normalize the user's spelling

Optimize language conditions

Recognize plural and singular

Store what the user said

Advanced Condition Coding

Annotations Reference

Condition Syntax Reference

DateTime Handler

Engine Scripting API Reference

Input Processing Path

Language Object Reference

Scripting

Engine scripting API

Groovy basics

Integration manager

Resource file manager

Scripts

Add a Groovy class

Add an integration

Add files to your solution

Annotate user inputs

Anonymize user data

Define a scripted context

Populate output parameters

Store input parameters

Test your bot

Run automated tests

Test your bot with Botium

Dialog Tester

Deploy your bot

Engine API

Versioning and Publishing

Publish your bot

Version Flags

Work with Version Flags

How to import solutions

SDK's

Android

JavaScript

Node.js

Getting started

After Match

Extract Entities

Class Manager

Introduction to transitions

Introduction to entities

Deal with Follow-ups

Dialogue and Context Model

Getting started with Teneo

Handle interruptions

Skip conditions

Teneo in 10 minutes

Flows and match requirements

Entities and After Match

Your First Flow

Your First Solution

Optimize your bot

Optimize classes

Improve the balance

Review Inputs

Refine your bot

Debug your bot in Tryout

Use Teneo's improvement tips

Troubleshooting

My flow doesn't trigger

My flow behaves unexpectedly

I see warnings in Tryout

Suggestions

root