Hero - Build your bot

Teneo supports scripting in two different levels, Global and Flow. On this page, you will understand more about the two levels and where to use which.

## Global Scripts
Global scripts are created and managed at the solution level. In the main solution window, click the 'Solution' tab, then choose 'Globals' on the left and choose the 'Scripts' tab. There, you will find an 'add' button to add scripts in multiple fields. Where you add your script not only determines when it is executed but also which data your script can access. There are two "levels": __Session__ and __Engine__.

![Global Scripts](//images.ctfassets.net/2vbtnveccz5s/2NuaXx94yt8efeTUYsOYPF/c0c3a92ffa9872cbabd68602a844bf90/multiple-scripts.png?classes=w60)

!!! Full details of accesible engine scripting methods is available [here](https://www.teneo.ai/documentation/latest/#/?id=component-api-reference) and to see which script is accessible from where can be found [here](https://www.teneo.ai/documentation/7.0.1/javadoc/engine-scripting-api/com/artisol/teneo/engine/core/engine/doc-files/engine_access_method_availability.htm).

### Session
Session scripts can be executed at various moments in a session. These scripts have read and write access to session data (like global variables or the input of the user). They are connected to a particular session.

#### Begin dialog
Scripts here will be performed once, at the start of each session. This script is commonly used to perform tasks that need to happen at the beginning of each session. For example, you might use this script to check if a certain parameter was included in the first request.

Depending on how this session began, the next script to execute will be either the 'New session' script or the 'Timed-out' session script.

#### New session
This script runs following the 'Begin Dialog' script, but only if the request *did not* contain session a session ID. The absence of a session ID in the request tells the engine it should start a new session and execute this script. This script is not commonly used. You should only use it if you explicitly want it to only run at the start of a *new* clean session.

#### Timed-out session
This script runs following the 'Begin Dialog' script, but only if the request *did* contain a session ID but the corresponding session was expired or is unknown. In this case, the engine will assume the session was timed out. The engine will start a new session and execute the 'Timed-out session' script. You should only use this script if you explicitly want it to only be executed for timed out or resumed sessions.

As previously stated, at the start of a session, the engine will always run the 'Begin Dialog' script and then either run the 'New session' script or the 'Timed-out session' script.

!!! More details on sessions can be found in the [Session Management](/article/deploy/engine-api#session-management) paragraph in the 'Deploy your bot' section.

#### Pre-processing
The 'Pre-processing' script is executed on each transaction, before the engine does any processing of the input. This means you can manipulate the user input string before it is tested against flow triggers or transitions. A more common use of the 'Pre-processing' script is to access other elements of the incoming HTTP request. For example, it is very commonly used to store values of URL parameters in global variables:

```groovy
if (engineEnvironment.getParameter("channel")) {
	channel = engineEnvironment.getParameter("channel")
}
```

#### Pre-matching
Scripts here are also executed on each transaction. They are run before the engine tests the user input against flow triggers or transitions, but after the sentences in the user input are separated for processing (sentence segmentation) and after the input is separated into words (tokenization). This script is not commonly used.

#### Post-processing
'Post-processing' scripts are executed after your solution has created a response, and consist of the output text, output URL, emotion, and output parameters. It is commonly used to run scripts that depend on the results of the flow processing, right before the final response is returned. It can also be used to change the response data. For example:

```groovy
if (channel == 'slack' && _.getOutputURL()) {
    _.setOutputText(_.getOutputText() + '\nMore details: ' + _.getOutputURL())
}
```

#### End dialog
Scripts here will be performed once, at the end of each session. They could, for example, be used to write session details to an external system or to close database connections.

#### Pre-logging
The 'Pre-logging' script is executed when the dialog has ended, but before the dialog been logged in Inquire. Therefore the script can both see and modify the content captured during the session before it has actually been logged.   
One use-case is to anonymize names, to either remove it or replace it with a common pseudonym like 'Jane Doe'. For example in the script below, we change the value in __Lib_sUserFirstName__, which stores the users first name, to Jane:

```groovy
_.getDialogHistoryUtilities().replaceVariables(['Lib_sUserFirstName'], 'Jane');
```

#### On top
'On-top scripts' will be executed whenever a flow becomes the top flow on the [flow stack](/studio/conversations/concepts/flow-stack) (either by being triggered or by regaining the top position after being interrupted by the triggering of another flow).

#### On drop
These scripts will be executed whenever a flow is finished and the task is removed.

### Engine
Engine scripts are only executed when a solution is loaded by the engine (typically when the engine is started) or when a solution is unloaded (typically when the engine is stopped). These scripts are not connected to a particular session. This means you can't directly use session-specific data (like global variables) in these scripts. You can, however, pass on the [EngineAccess and EngineEnvironment](/studio/scripting/concepts/engine-scripting-api) objects to the classes' methods defined here.

#### On Solution loaded
This script runs once when the solution is loaded into the engine's memory. It very commonly contains utility classes that are used throughout the solution. For example, you could add a class here that offers various string manipulation methods.

#### On Solution unloaded
This script runs once directly before the solution is unloaded. It is not a commonly used script field.

### Script execution order
A diagram outlining the order in which Teneo executes scripts (and other tasks) can be found in the reference section: [Input processing path](/studio/reference/input-processing-path).

## Flow Scripts
Flows can execute script code when they reach the top of the [flow stack](/studio/conversations/concepts/flow-stack) or when they are dropped off the flow stack. The flow scripts have access to both the global and flow variables (whereas the global On top and On drop scripts can only access global variables).

To find the scripts, open a flow, click the 'Flows' tab, and select 'Scripts'.

### On top
The On top script of a flow will be executed whenever the particular flow becomes the top flow on the flow stack (either by being triggered or by regaining the top position after being interrupted by the triggering of another flow).

### On drop
The On drop script of a flow will be executed when the flow has finished and is about to be dropped from the flow stack. It is commonly used to copy the value of a flow variable to a global variable with a limited life span:

```groovy
// Save flow variable coffeeSuggestion in global variable coffeeTypeInFocus
coffeeTypeInFocus = coffeeSuggestion

// Set the lifespan of the global variable
_.setSessVarLifespan('coffeeTypeInFocus',2)
```

### Executing scripts in the middle of a flow
The On top and On drop scripts are executed when they reach the top of the [flow stack](/studio/conversations/concepts/flow-stack) or when dropped off the flow stack. You may, however, want to execute a script at a specific point in a flow. In that case, you can use a [Script node](/studio/flows/how-to/add-a-script-to-your-flow#add-a-script-node). If it's a script you need to execute regularly in different flows, you can consider storing it in an [Integration](/studio/scripting/concepts/integration-manager).

## Ordering
With Multiple Global Scripts also comes Global Script Ordering which, similarly to the Global Listeners Ordering, allows users to set the order in which scripts of the same type are executed.

![multiple-scripts-ordering](//images.ctfassets.net/2vbtnveccz5s/3ulboPgbQgh86FxGlNU4rS/bb11d323d26ac8082b0b44ba082ba30b/multiple-scripts-ordering.png)

Scripts

Teneo supports scripting in two different levels, Global and Flow. On this page, you will understand more about the global level that is available on Studio Web and where to use which.

## Global Scripts
Global scripts are created and managed at the solution level. In the Solution Dashboard view, click on 'Scripts', in the 'Globals' tab. There, you create a script and place it in multiple fields. Where you add your script not only determines when it is executed but also which data your script can access. There are two "levels": __Session__ and __Engine__.

![multiple-scripts-web](//images.ctfassets.net/2vbtnveccz5s/18IvPxPIJy9Wpu8sE29PA5/93c71bef95a61bf0050d9f586544c4ca/multiple-scripts-web.png?classes=w60)

!!! Full details of accesible engine scripting methods is available [here](https://www.teneo.ai/documentation/latest/#/?id=component-api-reference) and to see which script is accessible from where can be found [here](https://www.teneo.ai/documentation/7.0.1/javadoc/engine-scripting-api/com/artisol/teneo/engine/core/engine/doc-files/engine_access_method_availability.htm).

### Session
Session scripts can be executed at various moments in a session. These scripts have read and write access to session data (like global variables or the input of the user). They are connected to a particular session.

#### Begin dialog
Scripts here will be performed once, at the start of each session. This script is commonly used to perform tasks that need to happen at the beginning of each session. For example, you might use this script to check if a certain parameter was included in the first request.

Depending on how this session began, the next script to execute will be either the 'New session' script or the 'Timed-out' session script.

#### New session
This script runs following the 'Begin Dialog' script, but only if the request *did not* contain session a session ID. The absence of a session ID in the request tells the engine it should start a new session and execute this script. This script is not commonly used. You should only use it if you explicitly want it to only run at the start of a *new* clean session.

#### Timed-out session
This script runs following the 'Begin Dialog' script, but only if the request *did* contain a session ID but the corresponding session was expired or is unknown. In this case, the engine will assume the session was timed out. The engine will start a new session and execute the 'Timed-out session' script. You should only use this script if you explicitly want it to only be executed for timed out or resumed sessions.

As previously stated, at the start of a session, the engine will always run the 'Begin Dialog' script and then either run the 'New session' script or the 'Timed-out session' script.

!!! More details on sessions can be found in the [Session Management](/article/deploy/engine-api#session-management) paragraph in the 'Deploy your bot' section.

#### Pre-processing
The 'Pre-processing' script is executed on each transaction, before the engine does any processing of the input. This means you can manipulate the user input string before it is tested against flow triggers or transitions. A more common use of the 'Pre-processing' script is to access other elements of the incoming HTTP request. For example, it is very commonly used to store values of URL parameters in global variables:

```groovy
if (engineEnvironment.getParameter("channel")) {
	channel = engineEnvironment.getParameter("channel")
}
```

#### Pre-matching
Scripts here are also executed on each transaction. They are run before the engine tests the user input against flow triggers or transitions, but after the sentences in the user input are separated for processing (sentence segmentation) and after the input is separated into words (tokenization). This script is not commonly used.

#### Post-processing
'Post-processing' scripts are executed after your solution has created a response, and consist of the output text, output URL, emotion, and output parameters. It is commonly used to run scripts that depend on the results of the flow processing, right before the final response is returned. It can also be used to change the response data. For example:

```groovy
if (channel == 'slack' && _.getOutputURL()) {
    _.setOutputText(_.getOutputText() + '\nMore details: ' + _.getOutputURL())
}
```

#### End dialog
Scripts here will be performed once, at the end of each session. They could, for example, be used to write session details to an external system or to close database connections.

#### Pre-logging
The 'Pre-logging' script is executed when the dialog has ended, but before the dialog been logged in Inquire. Therefore the script can both see and modify the content captured during the session before it has actually been logged.   
One use-case is to anonymize names, to either remove it or replace it with a common pseudonym like 'Jane Doe'. For example in the script below, we change the value in __Lib_sUserFirstName__, which stores the users first name, to Jane:

```groovy
_.getDialogHistoryUtilities().replaceVariables(['Lib_sUserFirstName'], 'Jane');
```

#### On top
'On-top scripts' will be executed whenever a flow becomes the top flow on the [flow stack](/studio/conversations/concepts/flow-stack) (either by being triggered or by regaining the top position after being interrupted by the triggering of another flow).

#### On drop
These scripts will be executed whenever a flow is finished and the task is removed.

### Engine
Engine scripts are only executed when a solution is loaded by the engine (typically when the engine is started) or when a solution is unloaded (typically when the engine is stopped). These scripts are not connected to a particular session. This means you can't directly use session-specific data (like global variables) in these scripts. You can, however, pass on the [EngineAccess and EngineEnvironment](/studio/scripting/concepts/engine-scripting-api) objects to the classes' methods defined here.

#### On Solution loaded
This script runs once when the solution is loaded into the engine's memory. It very commonly contains utility classes that are used throughout the solution. For example, you could add a class here that offers various string manipulation methods.

#### On Solution unloaded
This script runs once directly before the solution is unloaded. It is not a commonly used script field.

### Script execution order
A diagram outlining the order in which Teneo executes scripts (and other tasks) can be found in the reference section: [Input processing path](/studio/reference/input-processing-path).

## Ordering
With Multiple Global Scripts also comes Global Script Ordering which, similarly to the Global Listeners Ordering, allows users to set the order in which scripts of the same type are executed.

Here is how you change the ordering in Studio Web: 

![multiple-scripts-ordering-web](//videos.ctfassets.net/2vbtnveccz5s/4hPecdl2gBnK9YBqhxVzjT/05b39c7198fba03818b187f5775ded00/multiple-scripts-ordering-web.mp4)

Studio Web - Scripts

Build - Scripts

Analyze your bot

Analyze Log Data

Analyzing sessions

Augmenters

Concepts

Extract values with Augmenters

How To

Metadata

Running custom queries

Counting coffees with Metadata

Reference

Teneo Query Language Cookbook

Teneo Query Language Reference Guide

Teneo Query Language Syntax Overview

Teneo Query Language

Data hierarchy

Event

Property

Session

Transaction

How to

Explore session statistics

Find stuck flows

Generate session logs

Locate and view a session

Make use of skip constraints

Make use of sub queries

Query variables

Troubleshoot the Safetynet

Use relative dates in queries

Query Syntax

Command

Constraint

Meta-parameter

Selection

Transformer

Build your bot

Bot design

Best practices

Data footprint

Encrypting user data in sessions

Flow checklist

Plan your bot

Starting a new Teneo project

Writing good answers

Writing good examples

Conversations

Context restrictions

Flow stack

Greeting message

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

Outputs

Sub-Flows

Transitions

Intent triggers

Variables

Add a script to your flow

Branch at the beginning of a flow

Use TLML Syntax Match

Use a Sub-Flow

Use Bulk Import

Language Understanding

Annotations

Attached scripts

Language conditions

Language objects

Languages

Lexical resources

Libraries

Linguistic Modeling Language

Localization

Match requirements

Used words

Combine Match requirements

Create a solution in your language

Create your own language objects

Find language objects and entities

Localize a bot

Normalize the user's spelling

Optimize language conditions

Recognize plural and singular

Store what the user said

Advanced Condition Coding

Annotations Reference

Condition Syntax Reference

DateTime Handler

Engine Scripting API Reference

Input Processing Path

Language Object Reference

Scripting

Engine scripting API

Groovy basics

Integration manager

Resource file manager

Add a Groovy class

Add an integration

Add files to your solution

Annotate user inputs

Anonymize user data

Define a scripted context

Populate output parameters

Store input parameters

Test your bot

Run automated tests

Test your bot with Botium

Dialog Tester

Deploy your bot

Engine API

Versioning and Publishing

Publish your bot

Version Flags

Work with Version Flags

SDK's

Android

JavaScript

Node.js

Getting started

After Match

Extract Entities

Class Manager

Introduction to transitions

Introduction to entities

Deal with Follow-ups

Dialogue and Context Model

Getting started with Teneo

Handle interruptions

Skip conditions

Teneo in 10 minutes

Flows and match requirements

Entities and After Match

Your First Flow

Your First Solution

Optimize your bot

Optimize classes

Improve the balance

Review Inputs

Refine your bot

Debug your bot in Tryout

Use data to improve your bot

Use Teneo's improvement tips

Troubleshooting

My flow doesn't trigger

My flow behaves unexpectedly

I see warnings in Tryout

Suggestions

root

Table of Contents