Teneo Developers

Session Data model

This page explains how the session data model is structured and the type of data that is generated and used and may help understand how to perform Teneo Query Language (TQL) queries. For more details on how to query a Log Data Source in Teneo Studio, please visit the Log Data pages and the Teneo Query Language Manual.

Log Data Sources

Querying in the Teneo Platform is scoped to a single Log Data Source (LDS) at a time. A Log Data Source is a configurable container in the data layer which stores and indexes all the logs that are generated by a particular conversational AI application during a specific timeframe, as well as other user-generated data.

Log Data Sources are created by the data manager, for more information please see the this page.

The content of a Log Data Source is structured as shown in the figure below:

Structure of Log Data Source

A Log Data Source can consist of the following types of data:

  • Engine generated data (i.e., the logs) which are organized around sessions, transactions and events
  • User-generated data
  • Augmenters which extend the default log data
  • Solutions which are used for Engine-matching queries
  • Saved Results which store on-demand the results of queries performed by the user.

The different sorts of data are described in more details in the following sections.

Teneo Engine logs

Whenever a published conversational AI application is used, the conversation with the end-user is logged, storing not only the user inputs and the system outputs, but also information about the processing path performed by the application.

Log files consist of a set of sessions, which are made up of a series of transactions and events.

Teneo Engine logs

Thus, a session in the log file contains the full conversation between the end-user and the conversational AI application. Every dialogue turn in the conversation is represented in the log as a transaction, which starts upon a user request and ends when the application returns a response.

Transactions consist of a set of events, which contain not only the user input and the system output, but also information about the processing path performed by the application, namely the same information that can be obtained when using the Tryout in Teneo Studio.

Log properties

All data logged from sessions, transactions and events is modelled in the Teneo Platform as session, transaction or event properties. Examples of these properties are the beginning time of the session, the name of the traversed flow, or the value of a Flow variable.

Certain properties, such as variables and metadata, are logged by the Teneo Engine every time their value is updated. Therefore, they appear in the logs several times, first with the value they are initialized to (i.e., their default value), then for any subsequent values they attain along the transaction path, and/or the conversation. For instance, if a variable without an initial value is modified during the session, it will appear on different transactions with two different values. These variables can hold a value of any time, e.g., a string, a number or an array.

All property values are indexed and handled using the following data types:

  • Analyzed string: a string that has been tokenized and normalized before indexing. As a result, a list of tokens represent the original string, e.g., user input
  • Keyword: a string that has been indexed as-is (unmodified), e.g., flow name
  • Date: a timestamp with the format yyyy-MM-ddTHH:mm:ssZ, e.g., a session begin time. Note that all dates and times are stored in UTC time zone
  • Long: an integer value, e.g., transaction duration
  • Boolean: a Boolean value, e.g., annotation's variable typed Boolean
  • Double: a Double value, e.g., annotation's variable typed Double
  • Object: an object with named attributes, in JSON format, e.g., a collection of request parameters.

The list of log properties is given in details in the following subsections.
Session and Transaction properties are always generated (except for the properties related to variables and metadata), while properties related to events are only logged if said event takes place. For information on the timeline of log properties, please see the Log Timeline section.

Additional properties, such as those generated by augmenters, are explained in the section User-generated data.

Logging Session and Flow variables

Session and Flow variables are updated using scripts in Teneo. These variables are logged by the Teneo Engine every time a new value is assigned to the variable. Thus, when the variable contains an object, the object instance must be re-assigned in order to log any change. In contrast, when changing just the value of its content the variable update is not logged because it has not been assigned.
See the below table for some examples.

Variable changeEngine logComments
username=”John Doe”YesVariable username is assigned with a new value
date=new Date()YesVariable date is assigned with a new Date object having the current time
date.setTime(10000)NoThe value of the date object is updated but it is not logged because the date object is still the same.
date=(new Date()).setTime(10000)YesVariable date is logged because it is assigned a new instance of a Date
itinerary=[ origin: ”BCN”, destination: ”STO”]YesVariable itinerary is logged because it is assigned a new map object
itinerary.origin=”LON”NoVariable itinerary change is not logged because the object has not been re-assigned
new_itinerary=itinerary.clone() new_itinerary.origin=”LON” itinerary=new_itineraryYesVariable itinerary change is logged because it has been re-assigned with a new map object

Thus, variables must be re-assigned with a new instance of the object in order to get the value to be logged.

Additional information about how these variables are imported and can be queried in Teneo Studio can be found in the Teneo Query Language manual.

Session properties

Session logs can have the properties outlined in the below table.

NameTypeComments and Value constraints
beginTimedateTimestamp, session's first transaction begin time
botnamekeywordName of the published solution which generated the data
continuedFromkeywordSession continued from a previous session, session id of the previous session is displayed
endTimedateTimestamp, session's last transaction end time
engineVersionkeywordTeneo Engine version, e.g., 6.2.1, 7.0.3, 7.1.0
eventCountlongNumber of events in the session
idkeywordUnique ID of the session
solutionRevisionkeywordRevision number of the solution
solutionStatuskeywordAvailable values latest, stable
studioVersionkeywordTeneo Studio version, e.g., 6.2.1, 7.0.3, 7.1.0
transactionCountlongNumber of transactions in the session
lv:NAMEkeywordLog variable assigned in session, NAME is as set in Teneo Studio, e.g., lv:LAST_FLOW_SESSION
md:NAMEkeywordMetadata assigned to the session at session level
sv:TYPE:NAMEkeywordA session variable updated in this session, NAME is as set in Teneo Studio, e.g., sv:s:sCommand; logged every time it gets a new value

Transaction properties

Transactions can have the following properties:

NameTypeComments and Value constraints
durationlongTimespan of the transaction in milliseconds , i.e., time required by Engine to process the user input and generate the answer
idkeywordUnique id of the transaction
indexlongThe transaction's index within the session (starts at 0)
timedateTimestamp of transaction begin time
md:NAMEkeywordMetadata assigned to this transaction, queryable by metadata name
lv:NAMEkeywordLog variable assigned in this session; NAME is set as in Teneo Studio, e.g., lv:OUTPUT_NODE_IDS

Event properties

In the Teneo Platform, events are always nested under transactions and hold information that is not directly attached to sessions or transactions.

There are three types of events:

  • Request events which correspond to the inputs sent from the user to the Engine, namely user inputs
  • Path events which represent Engine's processing path between the reception of the request and the generation of the response, e.g., triggered Flow, listeners or scripts
  • Response which are the responses coming from the Engine to the user, i.e., the answer of the conversational AI application.

Event properties

Each transaction contains at least one Request event at the beginning, a Response event that ends the transaction, and one or more path events for Engine's processes.

Common event properties

The following properties belong to all event types:

NameTypeComments and Value constraints
eventIndexlongAny integer >= 0
typekeywordEvent type: request, event, path Specifying the event type may not always be strictly necessary but can nevertheless be done for performance reasons to make queries more efficient
fv:TYPE:NAMEkeywordFlow variable updated in this event; NAME is set as in Teneo Studio, e.g., fv:s:sTripDestination Logged every time it gets a new value
md:NAMEkeywordMetadata variable; NAME is set as in Teneo Studio Logged every time its value is assigned
sv:TYPE:NAMEkeywordSession variable updated in this event; NAME is as set in Teneo Studio, e.g., sv:s:sTopic Logged every time it gets a new value

Request event specific properties

On top of the Common event properties, Request events also have the following properties:

NameTypeComments and Value constraints
requestParametersobjectContains a map with all the parameters passed to Teneo Engine along the user input Its contents are queryable by using the NAME of any attribute in the map, e.g., e.requestParameter.pageURL
userInputkeywordActual string sent to Teneo Engine
userInputWordsanalyzed stringThe same as userInput, but stored and indexed as an analyzed string

Path Event specific properties

Path Events capture the different actions taken on the Engine side. They are indicated by the string property pathType and can be divided into three sub-types, corresponding to script actions, flow stack manipulation and listener / flow execution.

NameTypeComments and Value constraints
pathTypekeywordThis property is not always strictly necessary but can nevertheless be done for performance reasons to make queries more efficient pathType can be any of these types of path evens, organized into 3 groups: Related to scripts (session-script, flow-script, variable-change) Related to flow stack manipulation (raise-flow, pause-flow, continue-flow, resume-flow, drop-flow, input-processor-results) Related to flow/listener execution (match-requirement, data-action, flow-trigger, listener, output, transition, script, flow-node)

There are no separate path events for junctions and integrations due to the way these are logged: Junctions are logged as (empty) script nodes while integrations are logged as sub-flows which corresponds to how they are handled by the Engine.

These include global session events.

NameTypeComments and Value constraints
script-eventkeywordValid values: beginDialog, newSession, onTop, onDrop, preProcessing, preMatching, postProcessing, timedOutSession
script-idkeywordId of the script
vnamekeywordName of the script

Corresponds to the flow events onTop and onDrop.

NameTypeComments and Value constraints
fidkeywordId of the flow that holds the script
flow-instance-idkeywordflow-instance-id of the flow that holds the script
fnamekeywordName of the flow that holds the script
folderkeywordFolder of the flow that holds the script
vnamekeywordName of the script limited to flow script types in Teneo Studio onTop and onDrop

Indicates a side-effect variable change.

NameTypeComments and Value constraints
change-typekeywordValues limited to initialization, change and reset

This event takes place when a flow is added to the stack.

NameTypeComments and Value constraints
fidkeywordId of the flow that is raised
flow-instance-idkeywordflow-instance-id of the flow that is raised
fnamekeywordName of the flow that is raised
folderkeywordFolder of the flow that is raised
vidkeywordId of the vertex where the flow is raised
vnamekeywordName of the vertex where the flow is raised

This event takes place when a flow is "paused", i.e., another flow becomes the active flow.

NameTypeComments and Value constraints
fidkeywordId of the flow that is paused
flow-instance-idkeywordflow-instance-id of the flow that is paused
fnamekeywordName of the flow that is paused
folderkeywordFolder of the flow that is paused
vidkeywordId of the vertex where the flow is paused
vnamekeywordName of the vertex that is paused

This event takes place when a transition is matching and therefore the flow stays on top.

NameTypeComments and Value constraints
fidkeywordId of the flow that is continued
flow-instance-idkeywordflow-instance-id of the flow that is continued
fnamekeywordName of the flow that is continued
folderkeywordFolder of the flow that is continued
vidkeywordId of the vertex where the flow is continued
vnamekeywordName of the vertex where the flow is continued

This event takes place when a flow is resumed after being paused.

NameTypeComments and Value constraints
fidkeywordId of the flow that is resumed
flow-instance-idkeywordflow-instance-id of the flow that is resumed
fnamekeywordName of the flow that is resumed
folderkeywordFolder of the flow that is resumed
vidkeywordId of the vertex where the flow is resumed
vnamekeywordName of the vertex where the flow is resumed

This event takes place when a flow is dropped from the stack.

NameTypeComments and Value constraints
abortedkeywordValid values are true and false; true if the flow is forcefully dropped via scripting
fidkeywordId of the flow that is dropped
flow-instance-idkeywordflow-instance-id of the flow that is dropped
fnamekeywordName of the flow that is dropped
folderkeywordFolder of the flow that is dropped
stuckkeywordValid values are true and false; true if the flow is dropped because it was stuck
vidkeywordId of the vertex where the flow is dropped
vnamekeywordName of the vertex where the flow is dropped

This event takes place once the input processor has been executed and the results are available.

NameTypeComments and Value constraints
consistency-errorkeywordContains the error message and the stack trace if the invocation of an input processor threw an exception
consistentkeywordtrue if consistency-error is empty, that is, no error happened, otherwise false

This event takes place when a Match (requirement) was matched.

NameTypeComments and Value constraints
match-requirement-idkeywordId of the Match
match-requirement-typekeywordMatch type, valid values are syntax, class, entity, languageObject, script, context
parent-idkeywordId of the transition or trigger where the Match is defined
parent-typekeywordValid values are transition, intent-trigger
used-wordskeywordWhitespace-separated list of words
vnamekeywordName of this Match

This event takes place when an After Match is matched.

NameTypeComments and Value constraints
data-action-idkeywordId of the After Match
data-action-typekeywordAfter Match type, valid values are entity, languageObject, listener, script
parent-idkeywordId of the transition or trigger where the After Match is defined
parent-typekeywordValid values are transition, intent-trigger
used-wordskeywordWhitespace-separated list of words
vnamekeywordName of this After Match

This event takes place when a flow trigger matched.

NameTypeComments and Value constraints
fidkeywordId of the flow for this flow trigger
flow-instance-idkeywordflow-instance-id of the flow for this flow trigger
fnamekeywordName of the flow for this flow trigger
folderkeywordFolder of the flow for this flow trigger
used-wordskeywordWhitespace-separated list of words
vidkeywordId of this flow trigger
vnamekeywordName of this flow trigger
triggerTypekeywordType of flow trigger; valid values are intent-trigger, prompt-trigger

This event takes place when a listener was executed.

NameTypeComments and Value constraints
execution-orderkeywordValid values are pre and post
folderkeywordFolder of the flow for this listener
fidkeywordId of the flow for this listener
fnamekeywordName of the flow for this listener
flow-instance-idkeywordflow-instance-id of the flow for this listener
listener-typekeywordValid values are global, flow, flow-trigger and transition
vidkeywordId of this listener
vnamekeywordName of this listener
used-wordskeywordWhitespace-separated list of words

This event takes place when an output node was traversed.

NameTypeComments and Value constraints
emotionkeywordEmotion of this output node
fidkeywordId of the flow for this output node
flow-instance-idkeywordflow-instance-id of the flow for this output node
fnamekeywordName of the flow for this output node
folderkeywordFolder of the flow for this output node
max-revisitslongMaximum number of times an output node can be used
output-idkeywordId of the selected output
output-textkeywordText of the output
output-parameterskeywordOutput parameters
revisitslongNumber of times an output node has been used along the session
revisitablekeywordValid values are true and false; true if the output node is revisitable (up to Teneo Platform 4.1 logs only)
skippedkeywordValid values are true and false; true if the output node is skipped
urlkeywordUrl the application navigates to, if logged
vidkeywordId of this output node.
vnamekeywordName of this output node.

This event takes place when a transition is traversed.

NameTypeComments and Value constraints
fidkeywordId of the flow for this transition
flow-instance-idkeywordflow-instance-id of the flow for this transition
fnamekeywordName of the flow for this transition
folderkeywordFolder of the flow for this transition
input-consumingkeywordWhether the transition is input consuming or not; valid values are true and false
vidkeywordId of the transition vertex
vnamekeywordName of the transition vertex

This event takes place when a script node was traversed.

NameTypeComments and Value constraints
fidkeywordId of the flow for this script node
flow-instance-idkeywordflow-instance-id of the flow for this script node
fnamekeywordName of the flow for this script node
folderkeywordFolder of the flow for this script node
vidkeywordId of this script node
vnamekeywordName of this script node

This event takes place when a flow node was traversed.

NameTypeComments and Value constraints
fidkeywordId of the flow for this flow node
flow-instance-idkeywordflow-instance-id of the flow for this flow node
flow-node-typekeywordValid values are subflow and routing
fnamekeywordName of the flow for this flow node
folderkeywordFolder of the flow for this flow node
target-flow-idkeywordId of the flow where to hop on from the current flow
target-flow-namekeywordName of the flow where to hop on from the current flow
vidkeywordId of this script node
vnamekeywordName of this script flow node
Annotations

Annotations may be created in the processing paths of the following types of path event: input-processor-results, session-script or listeners.

They have the following properties:

NameTypeComments and Value constraints
actionkeywordValid values are added, removed or updated
namekeywordName of the annotation either given by the input processor or by the user depending on how the annotation is created
sentence-indexkeywordAssuming the user input is split in several sentences, it indicates which sentence the annotation belongs to; it is 0 if the user input contains a single sentence
variablesMap<string,typedObject>It provides additional information about the annotations, e.g., confidence score, sentence length, etc. Variables are logged every time they get a new value
word-indiceslongAssuming the sentence can be split into several words or tokens, it contains which words hold the annotation

Response event specific properties

NameTypeComments and Value constraints
answerTextkeywordActual string returned by Teneo Engine
answerTextWordsanalyzed stringSame as answerText, but it is analyzed during indexing
emotionkeywordName of the emotion returned by Teneo Engine
viewVariablesobjectContains a map with all the response parameters returned by Teneo Engine along the system answer. Its content is queryable by using the NAME of any attribute in the map, e.g., e.viewVariables.url

User-generated data

A Log Data Source may also contain user-generated data such as Augmenters, Saved Results from queries, etc.

Augmenters

Augmenters are new property fields generated by pre-calculations on existing log data. Augmenters extend default log data by enriching or summarizing it in a format that can later be accessed by standard queries. There are two types of Augmenters: adorners and aggregators.

Augmenters can only be created in the Teneo Log Data Manager frontend, using either Teneo Query Language (TQL) or Groovy. And, once created, they can be edited, disabled, or deleted.

The following sections introduce adorners and aggregators, but for more information please see the Augmenter section.

Adorners

As the name suggest, adorners allow to extend the data by furnishing it with additional or more precise information in order to simplify a query syntax or speed up its performance. For instance, to single out all sessions with at least one user input falling into the safetynet of a solution, an adorner can be created to add this property directly to the session level.

Adorners cannot be built on top of other adorners, in order to avoid dependencies between them, but they can be used with aggregators.

Once created, adorner data is stored along the rest of properties listed in the Teneo Engine logs section above. Therefore, it is possible to combine log properties with adornments in a single same query.

Adorner property names follow the below, specific pattern:

tql

1<LEVEL.a.TYPE:name>
2

where:

  • LEVEL indicates if the property is stored at session (s), transaction (t) or event (e) level
  • a stands for adorner
  • TYPE indicates the data type (see below table)
  • name (following the colon) is the adorner name provided at creation.
SymbolTypeSupported in...
bBooleanAdorners and aggregators
binbinaryAdorners and aggregators
ddateAdorners and aggregators
gpgeo_pointAdorners and aggregators
ninteger number (mapped as long)Adorners and aggregators
ffloating point number (mapped as double)Adorners and aggregators
sstringAdorners and aggregators
aarrayAdorners only

Thus, adorners generate new properties with the following characteristics:

NameTypeValue constraints
<LEVEL.a.TYPE:name>Boolean, binary, date, geo_point, long, double, keyword, arrayInteger numbers are indexed as Long, and Strings are indexed as keywords

Aggregators

Aggregators allow the construction of summaries over event, transaction, or session properties, including those generated by adorners. They simplify and speed up queries and post-query processing to obtain final counts. For example, an aggregator can be created at session level to store the number of inputs falling into the safetynet. These summary counts are automatically updated every time new data is imported.

Aggregators cannot be built on top of other aggregators in order to avoid dependencies among them. Once created, aggregated values are not stored along the regular log properties, but aside, as a detached division in the data structure. For this reason, they cannot be used directly as query constraints in regular queries. However, they can be used in sub-queries, which may serve the same purpose.

Aggregator's counts are computed around dates, and they keys indicated by the user when the aggregator is created. A single aggregator can contain more than one key, e.g., one key which contains the counts for each flow identifier, and another key which has the counts for each folder name. That way it is possible to group several summary counts in a single aggregator.

The aggregator keys follow the below, specific pattern:

tql

1<TYPE:name>
2

where:

  • TYPE indicates the data type (see the above table for values), and
  • name (following the colon) is the key name provided on creation of the aggregator

Thus, aggregators data contain the following properties:

NameTypeValue constraints
countlongNumber of times that <PREFIX:name> matches its condition on <date>.
datedateThe day for which the counts are calculated, formatted as yyyy-MM-dd.
<PREFIX:name>Boolean, binary, date, geo_point, long, double, keywordInteger numbers are indexed as Long, and Strings are indexed as keywords.
versionlongVersion number of the aggregator.
weekkeywordWeek number within the year, formatted as ww-yyyy.

Note that, as a result, date, week, version and count are reserved words that cannot be used as names in the aggregator key.

Saved Results

The Teneo Platform allows saving query results so they can be reused in subsequent queries. Saved Results can be used for obtaining intermediate results that can then be uses in later queries, or to save results that can be pulled out by other applications, such as Business Intelligence tools, or just to keep them for future reference.

Saved Results are not stored along the rest of the data properties. Thus, its content is neither updated nor removed when a Log Data Source is re-imported, or its configuration changed.

For more information on how to store, use and manage Saved results, please refer to the Log Data Source window section and the Teneo Query Language manual.

Appendix Log Timeline

Logs exist ONLY if the solution generates them. The log sequence described in this section is approximate and may vary depending on the solution.

Session

A session with inputs and responses contains one or more transactions, as shown in the following diagram:

Example of session

Upon reception of a user input, the first request is generated, logging information regarding the beginning of the session and the first transaction. For each transaction, the system logs the beginning and the duration of said transaction. All transactions have the same structure, which will be explained in the following subsection.

However, within the first transaction, transaction 0, there is an initialization header that may contain the logs of the following events (in order):

  • session variables initialization: a single event that contains all session variables that are initialized with a default value. The following Teneo Query Language (TQL) example retrieves the initial value of a particular session variable named <NAME_1> which is assigned as a string (s:):

    tql

    1listAll e.sv:s:<NAME_1> : e.pathType == "variable-change", e.change-type == "initialization"
    2
  • begin dialog global script: this event reports the execution of the global begin dialog script if it exists, along with any session variable change. The following TQL example retrieves the value of a particular session variable named <NAME_1> which has been updated within the begin dialog script and has been assigned a string (:s):

    tql

    1listAll e.sv:s:<NAME_1> : e.pathType == "session-script", e.vname == "beginDialog"
    2
  • new session global script: this event reports the execution of the global new session script if it exists, along with any session variable change. The following TQL example retrieves the value of a particular session variable named <NAME_1> that has been updated within the new session script and has been assigned a string (s:):

    tql

    1listAll e.sv:s:s<NAME_1> : e.pathType == "session-script", e.vname == "newSession"
    2

Transactions

Transactions have the following phases:

Transaction phases

Reception of the Request

When user input is received, a Request event is generated, and the transaction starts. Very roughly, a series of path events (i.e., the processing path) occur that lead to the evaluation of the triggers in the solution and the generation of a response. These path events vary depending on the input and how the solution is built.

The example below corresponds to a request followed by pre-processing and pre-matching session events, plus a global pre-listener, before trigger evaluation takes place.

Request example

Response

If no matches occur, or once the processing path has been completed because the transaction has consumed all user input, the system executes a last session script (named postProcessing) and, optionally, may modify one or more variables' values. The Response is generated, and the control is then returned to the user.

Response example

Processing path

The processing path varies slightly depending on the success of triggers, which depend on the input and the solution itself, or the estate of the flow stack. This section provides a few, non-exhaustive examples of typical processing paths that may occur in Teneo.

If no triggers in the solution are matched, the system will proceed to finish the transaction, see theResponse section, and path event properties are logged ONLY if the event has occurred!

Basic flow processing when the flow stack is empty

If a trigger's Match is matched, a flow is raised (which generates a path event of type raise-flow) and added to the flow stack. Then, the request begins to be processed, generating a log chain such as the one pictured below.

Log chain

In general terms, this sequence of events takes place when processing a flow:

  • The flow starts with:
    • a raise-flow path event
    • a session_script path event
    • a flow_script path event associated to raising the flow
  • The flow is executed
  • The flow terminates with:
    • a session_script path event associated to dropping the flow
    • a flow_script path event associated to dropping the flow
    • a drop-flow path event.
Sub-flows and Integrations

If a flow (flow A) contains a sub-flow or an integration (henceforth flow B), the parent flow begins the execution as usual until it is interrupted by flow B, generating the following set of events:

Example with Sub-flow/Integration

Where:

  • Flow A is raised as described in the previous section
  • when the sub-flow or integration kicks in, flow A is paused, and flow B is raised (Note that the sequence of events when raising and dropping a sub-flow or integration is different from those taking place in a regular flow and are described below)
  • Flow A is resumed, being processed from the point where it was paused

The execution of a sub-flow or integration, shown below, is slightly different from a regular flow:

Execution of Sub-flow/Integration

In case of sub-flows or integrations, the following path events occur:

  • a raise-flow path event
  • a session-script path event (onTop)
  • a script path event
  • a session-script path event (onDrop)
  • the execution of the sub-flow/integration
  • a drop-flow path event.

As mentioned, Flow A is then resumed from the point where it was paused.

Order of listeners

Listeners are always active but only act (i.e., they execute an action, such as changing the value of a variable) when there is a match with the user input. There are several types of listeners, which work in this order:

  • Global Pre-listener happens before any trigger matching
  • Global Post-listener is evaluated right after a raise-flow event and right before any flow listener
  • Flow listeners are evaluated after the trigger matching (raise-flow) and Global Post-listener, if any
  • Trigger listeners are evaluated after any transition through the flow.

In the following example, a request is received and, before any trigger is evaluated, the preProcessing and PreMatching session scripts are executed. Then, the Global Pre-listener comes into action if its TLML syntax is matched before any flow-trigger matching happens.

Example of order of Listeners

A flow is triggered and raised and then the rest of listeners act (of course, if their TLML syntax is matched). Finally, the flow execution carries on with the session and flow script path events, as explained in previous sections.

Example of Listeners

Output parameters and Responses

The following example shows the events that happen when the conversational AI application generates an output - note that it may generate a response by traversing several output nodes separated by other transitions.

In this case, the execution of the flow results in the generation of outputs, then the flow is dropped.

Example of Output generation

Post-processing takes place and the Response is generated.

Example of post-processing and response generation