Teneo Developers

Teneo Studio

Testable working Master

The Teneo 6.0 release brings various improvements to the Localization functionality of Teneo Studio; the Master solution is now a working solution as any other solution and not just a template as up till now, making it possible to select which content to share with the Local solutions. This means that a Master solution can contain content which is shared with Local solutions, but also content which is only in the Master solution.

Each document (Flow, Entity, Script, Integration, ..., etc.) within the Master solution can be set to "include" or "exclude". This way, only documents set to "include" will be available to Local solutions.

If a document first is set to include (and branched to at least one local solution) and later on is set to exclude, it means it is paused from branching, but will still remain in the local solution(s).

Branching will start again if the document again is included. This allows users to temporary pause updates for a Flow/integration/listener, ... etc. while expanding/changing/testing it for example. If the "first included-later excluded" document is deleted in the master solution, it is also deleted from the local solution(s).

The great advantage of this new behavior is that the Master solution becomes testable (Auto-test and Try Out) and can be published as a complete solution - it can become a fully functional solution! The Local solution can be created at any point and in the Master the user can set the "include" flag to selected documents without compromising the current Master solution.

The main changes in the Localization functionality (previously known as "Master-Local") are described in the below sections.

Select documents to share

In the Master solution it is now possible to select which documents are included in or excluded from the local solution(s).

The top ribbons of Flows, Language Objects, Entities, etc., now includes the Branching area with the two options.

Include and Exclude buttons

In the Solution Explorer view allows to multi-select various objects and, again, in the top ribbon the two new buttons a available to include/exclude various documents in one go.

Visualization of the Master-controlled documents

In a Master solution, the documents shared with Local solutions are displayed with a 'down-arrow' icon.

Master controlled documents in the Master solution

In a Local solution, the documents which are Master-controlled, are displayed with a shield to emphasize the documents relation to the Master solution.

Master controlled documents in the local solution

Order groups

Order groups added in a Master solution are now always added as an update in the Local solution. Accepting the update will add the Order group to the Local solution at the bottom of the list of Order groups, regardless of what position it had in the Master solution.

The ordering itself and any properties of an Order group, such as its name and the Triggers contained in it remains fully Local-controlled and such changes in the Master solution will not result in updates in the Local solution(s).

When a Local solution is presented with Flow updates that contain new Intent Triggers belonging to a non-existing Order group in the Local solution, the application of the Flow updates will automatically apply the Order group updates and assign the new Intent Trigger to the same Order group in the Local solution.

Branch solution and include a template solution

When a solution is branched, it is possible to select Create from Template to import additional content from a template solution on top of the Master-controlled content. This is done to facilitate, for example, the import of a Teneo Dialogue Resource in Local solutions.

When a template solution is included at branching, the Order groups from the template will end up at the top of the Intent/Prompt Trigger ordering, above the Order groups from the Master solution. The internal ordering from each solution will be kept.

The Default Order group in the template solution will become the default group in the newly created Local solution; it might therefore be a good idea to review and if necessary adapt the Trigger ordering once a Local solution has been created.

When creating a Local solution and including a template solution at branching, only the file resources from the template solution will be added to the Local solution. No files from the Master solution will be added to the Local solution.

Merge import and branch import into Local solutions

When performing merge import or branch import of a solution into a Local solution, any Metadata and Global scripts from the imported solution are ignored to prevent Local solutions from ending up with orphan Metadata / Global scripts that cannot be edited (since these documents are fully Master-controlled).

For merge import or branch import, the Order groups from the imported solution will end up at the top of the Intent / Prompt Trigger ordering, above the Order groups from the Master solution and the default group will be the one set as default in the imported solution, just as when creating a Local solution and including a template.

During branch import, only file resources from the imported solution will be added to the local solution.

Copy Local Flow to Master

In case a Local solution contains a Flow, which the Master solution should also contain, it is possible to search for the Local Flow in the Master solution and copy/paste it to the Master solution. If the Flow should be shared with the Local solution, the Master-user will need to set the Include option for Master-controlled documents, and in the Local solution, the, now, new Flow will appear as an update in the My work tab; note that it is recommended to remove the original Local Flow before applying the update.

My work tab

The available updates in a Local solution are viewed in the My work tab in the backstage of Teneo Studio. The buttons to update documents have been reworked to display even more clearly the difference between the two: Update ALL xx items or Update Selected items; and the user is prompted to confirm the update of documents when the button is clicked.

Delete Master-controlled folders

When a Local solution receives an update to delete a Master-controlled folder, any Local documents in the Master-controlled folder will not be deleted, and the folder itself will not be deleted either but rather unlinked from the Master solution.

Along with the introduction of the Recycle Bin, the following behavior has been defined for Localization setups:

  • Deleting a document in Master will result in a delete update for the Local solution that will send the document into the Recycle Bin
  • Restoring a document from the Recycle Bin in Master will result in a restore from Recycle Bin in Local
  • Deleting a Master controlled folder and its content will result in an unlink update for the folder and delete updates for the contents in the Local solution; applying only the unlink update will also apply the delete for its content, because an unlinked folder cannot have Master controlled documents inside
  • Deleting a Master controlled Class will result in an unlink update for the Class in the Local solution
  • To link back a folder, it can be restored from the Recycle Bin in the Master solution and the link-change applied in the Local solution
  • If, for example, in Master a Flow is restored and its original location doesn't exist any more, the folder structure will be created (this is due to how the Recycle Bin works) and in Local, there will be updates both for the Flow and the (re)created folders.


Master controlled documents cannot be deleted in Local anymore, a new button is added in the Local solution that allows to reset the Local document to the Master.

Reset button in the top ribbon

Previously, if a user wanted to re-link a detached Local Flow with the Master Flow, their only option was to delete the Local Flow and accept the update available in the My Work tab afterwards; now they can either reset it to the Master version or restore it to any of the versions prior to it being detached.

Deletion and restore of documents in Localization setups is described further in the User Guide.

Migration Ordering and Order groups

Before Teneo 6, Order groups in Master solutions were only propagated to Local solution when branching a new Local solution for the first time.

Any Order groups that already existed in the Master solution when branching a new Local solution are linked automatically during the migration upgrade to Teneo 6 and the Local solution does not need to be updated with those Order groups from the Master solution.

Order groups that were added to the Master solution after branching will appear as a Master update in the Local solution.

Note that during the migration upgrade to Teneo 6, Local Order groups are automatically linked to Master Order groups if both of them share the same name. It is recommended to align their names before upgrading to avoid any unnecessary Master updates. The names can be changed after the upgrade if desired. Also, note that this is not a mandatory step.

It is also possible to apply the updates and move the Intent Triggers in the new Local solution to the new Order groups and fix the ordering in the Local solution.

Read more about the Localization setup in the User Guide

Match Requirements and Data Actions

To provide a more abstract and simple way of controlling Flow triggering and conditional actions, the Triggers and conditional Transitions come with a completely new way of adding conditions, examples, Classes, etc. in the form of Match Requirements.

This means that the former Class and Syntax Triggers have been merged into Intent Triggers, allowing users to define multiple criteria for matching an input, each one potentially of a different type.

On top of the Match Requirements, users can specify Data Actions, which are actions that are executed each time the Trigger is triggered. Both Match Requirements and Data actions can be applied to conditional transitions.

The Intent Triggers and Transitions displays an icon-only summary of the content of the Trigger/Transition in the Flow graph; the first row shows the defined Match Requirement(s) while the second row displays an overview of the defined Data Actions. Both rows displays the defined properties in their execution order.

Intent Trigger containing Match Requirements and Data Actions

With the fusion of the Triggers, Order groups are no longer split between Syntax and Class Trigger types, and the Intent Triggers can be placed in any Order group no matter which Match Requirement is defined in the properties of the Trigger.

Both the Match Requirements and Data Actions are searchable in the Advanced search of Teneo Studio.

Match Requirements

In Teneo 6.0 Intent Triggers and conditional Transitions can match on one or more Match Requirements; and each Trigger/Transition can contain as many Match Requirements as needed.

The following Match Requirement types are available:

  • Class Match Requirement
  • Condition Match Requirement
  • Entity Match Requirement
  • Language Object Match Requirement
  • Script Match Requirement
  • Context Match Requirement covering:
    • Global Variable Context
    • Flow Variable Context
    • Scripted Context

For each user input, the Match Requirement list is checked top to bottom, executing each Match Requirement against the input. If all the Match Requirements match, the Trigger / Transition is considered to trigger for the selected entry, so the following nodes in the Flow will be executed. If at least one Match Requirement doesn't match, the rest of the list is left unevaluated.

Match Requirements are available in the new Match Requirements section of Triggers / Transitions. The section provides a dropdown menu to select and add the wanted Match Requirement type.

Add Match Requirements

Whenever a new Match Requirement is added, it is added at the top of the list; all Match Requirements have in their top-right corner a handle (dotted scare field) to drag/drop the Match Requirement into the wanted order, and a delete ('x') button is available to remove them if necessary.

More information about Match Requirements and types is available in the new Match Requirement section of the User Guide.

Data Actions

On top of the Match Requirements that determine when an Intent Trigger / Transition trigger, the Trigger / Transition can also contain Data Actions which are executed whenever the Trigger or Transition is triggered by a user input to, for example, execute a script, set a Variable value, etc.

The below listed types of Data Actions are available:

  • Entity Data Action
  • Language Object Data Action
  • Listener Data Action (substitutes the former Trigger Post Listeners)
  • Script Data Action

The Data Actions are available in the new Data Actions section available below the Match Requirements of the Trigger / Transition. The section provides a dropdown menu to select and add the wanted Data Action type.

Add Data Actions

Read more about the Data Actions and types in the User Guide.

Condition Building Assistant

The Condition Building Assistant known from the Condition editor (writing some letters, and pressing Ctrl+space) also works in Match Requirements of the types Language Object and Entity to obtain suggestions on objects in the solution or an assigned lexical resource.

Match Requirements and Data Actions can be searched for in the Search tab of Teneo Studio; the search behavior differs a little depending on which elements are searched for:

  • Elements based on language components (i.e. Language Objects and Entities): these elements are referenced by Name in Match Requirements and Data Actions, and as such searching the Name will will display Match Requirements and Data Actions that are linked to them as well as their definitions (provided the appropriate search criteria are set in the Advanced Search tab)
  • Elements not based on language (i.e. Classes, Variables or Scripted Contexts): these elements are referenced by Id in Match Requirements and Data Actions, so a search for their Id will show the Match Requirement and Data Actions linked to them, while a search on their Name will show their definitions (provided the appropriate search criteria are set in the Advanced Search tab)
  • Script elements containing code: these are matched if the search pattern match either their expression, condition or name (depending on the selected criteria for the search).

Import and upgrade

When importing solutions from previous versions of Teneo Studio, the Syntax Triggers will be converted into Intent Triggers with Condition Match Requirements, while Class Triggers are converted into Intent Triggers with Class Match Requirements. Examples (both positive and negative) are, of course, also added to the new trigger type. For both trigger types, if in previous versions they had any listener or context assignments, these are converted as well to Match Requirements/Data Actions. Of course, conditional Transitions will be converted into conditional Transitions with Condition Match Requirements.

Note that the former Class Triggers will also generate a Class on import to Teneo 6.0, adding the positive examples and any linked examples as training data of the Class.

A Syntax Triggers or a conditional Transitions with an empty condition:

  • with 1 or more Context restrictions will become an Intent Trigger / conditional Transition with the Context Restriction migrated to become Context Match Requirements, but the empty condition is ignored / not migrated
  • with no Context restrictions will become an Intent Trigger / conditional Transition with a single Script Match Requirement with the content true.

Class Manager

Since Teneo 5.1, a Machine Learning model is trained with each solution to detect the intent of the current user input; this model, that originally was associated to Class Triggers, has been isolated in a new Class Manager window, so it can be managed in isolation and as a separate step in solution design.

Class Manager window

The Class Manager window provides the user of Teneo Studio with an overview of the Classes available in a solution showing the list of Classes and the number of Training Data examples available; the Class details view (right side of the window) allows to easily edit a selected Class, giving it a description or updating the training data.

Classes in edit-mode are locked allowing multiple users to work on the machine learning model at the same time. Furthermore, the Import Classes button in the top ribbon of the window allows users to easily import Classes and training data from plain text files.

The Class Manager allows to filter on both the Class list and the training data. The two available filters operate directly over the lists, and are kept while the user is working on Classes; so, if a filter is applied for the Training Data, that filter will be applied to the Training Data of all the Classes selected in the list. Both filters are case insensitive.

Classes can now easily be imported from an external file in TSV format, i.e. a file with one line per training data, where each line contains a valid Class name separated from the training data example with a tab.

Learn more about the Class Manager in the User Guide.

Model training

Training of the machine learning model will now happen when the user performs changes to the Classes in the Class Manager, and the training request is as before displayed in the try Out panel.

In a multi-user setup, the model will be available to the user whose save action initiated the training as soon as the 'Model Update Completed' message is available in Try Out; other users editing the same solution will continue using the old model until the Try Out is reloaded. In this case, the 'Model Update Completed' message in Try Out indicates when the model is ready for the second user.

On top of this, when a user has tried to perform an Auto-test or publication of the solution with a model not ready message due to the old model not being available in the cache, training of the machine learning model will now automatically start.

Learn more about Machine Learning in Teneo in the Knowledge Base.

Import and upgrade of disabled Class Triggers

When importing or upgrading solutions from previous releases (5.1.2 or prior) any Class Trigger residing in a disabled Flow will not result in a Class nor a Class Match Requirement being created in the solution. The examples of the Trigger will be added as examples of the Trigger in the disabled Flow. This change is to ensure the behavior of the upgraded solution remains as it was before the upgrade since a Class Trigger in disabled Flow would not previously create a Class in the model sent to Predict.

Class Performance

Teneo 6.0 brings native analysis of the classifier model using standard machine learning (ML) techniques in the form of cross validation to help users monitor and check the classifier's health even when no test data set is available or in place yet, such as in early development phases. The Class Performance provides a way for the user to check the performance of the machine learning model and analyze which Classes conflict with one another.

The evaluation of the model is performed using a Cross Validation process, i.e. all the training data examples of all the Classes are split into K folds, and for each fold, a ML model is trained with the rest of the K-1 folds; once the training is completed, the performance of the ML model is evaluated against the retrained fold. The results of all these evaluations are averaged to get an estimation of the real performance of the model.

It is important to remember that Cross Validation is an estimation of the performance of the model and that it is stochastic in nature, i.e. different executions of the Cross Validation process may give different results as the training data is randomly split into folds. Results would probably be stable for homogeneous classes with a high number of training data examples; a high variance could be symptom of excessive heterogenicity among the training data for some classes.

The following metrics are used to evaluate the performance; these are standard metrics for performance measurement in machine learning models:

  • Precision measures the percentage of the detected Classes that were really positive matches (how much can we rely on our classifier having marked as positive only training data that is positive)
  • Recall measures, from all the positive matches, how many of them were successfully retrieved (how sure is our classifier of having retrieved all the existent positives in the dataset)
  • F1 is the harmonic means of Precision and Recall (usually used as a general measure of classifier performance).

The Class Performance view, available in the backstage of Teneo Studio under Optimization, provides two visualizations:

  • Confidence Threshold Graph which gives an estimation of the behavior of the model for different confidence thresholds, and
  • Class Performance Table which shows the per-class performance of the machine learning model.

Class Performance view

Confidence Threshold Graph

Whenever a new input arrives to the conversational AI application, the machine learning model analyzes that input and generates a set of Class predictions, i.e. for each Class in the model, it assigns a probability for the input to belong to that Class. If the probability value of the most probable Class exceeds a solution-wise confidence threshold, an annotation is created for that Class and Triggers that depend on that Class are triggered.

This solution threshold is set up under the assumption that predictions with a very low degree of confidence will most probably be wrong; so the thresholding process can be thought of as a binary classifier that determines whether the predictions of the machine learning model are reliable for a given input or not (based only on the prediction confidence).

The purpose of the Confidence Threshold Graph is to provide a tool to analyze the estimated performance of the Classes in the solution with regard to this threshold setting.

Confidence Threshold Graph

The view shows the values of the classification metrics for the thresholding process for each value of the confidence threshold, in the [0, 1] range; in this context, the performance metrics can be interpreted in the following way:

  • Precision measures the percentage of the accepted inputs (classifications with a confidence over the threshold) that were rightfully accepted
  • Recall measures the percentage of the correct inputs (training data that was correctly classified by the model) that were accepted by the threshold
  • F1 has the usual meaning as the harmonic mean between the other two metrics.

The values on this graph can be used to decide where to set the solution confidence threshold.

Class Performance Table

The Class Performance Table shows the performance metrics for each of the Classes in the solution, including how many errors correspond to false positives (FP), which are those predictions where the classifier assigned that Class when it should have assigned another, and to false negatives (FN), which are those predictions where the classifier assigned another class, when it should have assigned the analyzed one.

Class Performance Table

The table displays one row for each Class and a single row for the average values for all Classes. For each row, the following columns are displayed:

  • Class name
  • Precision, Recall, F1: the binary classification metrics for the row's Class
  • Examples: number of Training Data examples
  • Conflicting Classes: shows the number of mistaken predictions of the model.

When cross validation has been performed more than two times, the user can select to compare the current results with results from a previous version. the differences between the two are then highlighted in the table: green in the cases where the metric has improved and red in the opposite case.

Learn more about Class Performance in the User Guide.

TODO Triggers and Transitions

A new feature marking new Flows as "TODO" when no Match Requirements, Data Actions (Intent Triggers and Transitions) or Output nodes has been implemented resulting in an approach including more guidance for the first-time user, more possibilities for separation of responsibility in the development workflow, whilst not slowing down the process for the expert users.

Flow graph with TODO label

This approach is built on the principles of:

  • Define / implement to prompt the solution developer to make the required changes for a functional Flow
  • Rapid prototyping of Flows without needing to implement them to gather an agreed overall design without being concerned about the implementation details
  • Smart one-click Generate options for implementing appropriate matching on Triggers and Transitions.

The TODO labels do not have any effect on the solution functionality at execution time, their only purpose is to remind the solution developer of the pending Triggers / Transitions / Output nodes to implement; a Trigger (or Transition) with no Match Requirements will never match.

Read more in the User Guide

Version History

This release brings version and version history to a long list of Studio documents allowing the user to view the version history and restore documents to previous versions.

The following documents are now versioned and their version history is available either in the backstage of the document or by opening the history clicking the new Open History button.

Versioned documents
FlowLanguage ObjectEntity
ClassFolderGlobal Variable
File resourcePublish EnvironmentLexical Assignment
OrderingSolution Properties

File resources can now be edited by uploading a new one or editing them; it is also possible to download them.

For Lexical assignments, a track of the assignments and un-assignments to the solution of the lexical resources is kept in its version history where it is no possible to see which lexical resources are assigned for each version.

A Solution Log is also introduced with information related to each revision of the solution, providing information of which changes were performed, on which documents, who did the changes, at what time, etc.

Solution Log

The revision number is what defines the version of a solution, therefore its version is the latest revision number. The Solution Log cannot be cleaned, and it will contain all the changes from the creation of the solution onwards.

Read more about Version History and Solution Log.

Recycle Bin

The Teneo 6.0 release comes with a Recycle Bin, which allows Studio users to delete documents without removing them completely from the solution; this allows to restore the documents at a later stage if found needed in the solution. The below listed documents can be deleted and restored from the Recycle Bin.

Restorable documents
FlowLanguage ObjectEntity
ClassFolderGlobal Variable
EmotionIntegrationFile Resource
Publish Environment

The Recycle Bin, available through the Recycle Bin button in the lower part of the Solution Explorer view, allows to see deleted documents, search by name or filter by type; it is also possible to order by name, branchable state, time of deletion, deleted by or location. Double-clicking will open in read-only mode for Flows, Entities and Language Objects, while double-clicking other documents will open their version history. It is currently not possible to open a deleted a Publish Environment and a message will instead be displayed in order to first restore it.

Visit this page of the User Guide to learn more about the Recycle Bin and its options.

Solution Properties

The work to implement version history also brings changes to the Solution Properties in the backstage of Teneo Studio which has been split into two areas: Properties and Owners.

The Markdown component used for the solution notes has also been replaced with a new one to provide better support for formatting solution notes including an option to create tables.

Read more about Solution Properties in the User Guide


As part of the work around version history, the default metadata definitions are removed meaning that when a solution is created no default metadata definitions will be added.

It is also not possible to create and edit composite metadata anymore, only enabling/disabling.

On top of this, it is now possible to create a new type of metadata by setting it to bundle, allowing to add sub-definitions to it.

The entire display of Metadata as well as how the user edits these has been completely reworked to be aligned with how other Global elements are edited, and the view now presents an editor in the right-side of screen, while the middle presents the list of the available definitions.

New Metadata view

Read more about Metadata in the User Guide

Try Out

The Try Out functionality known from former Teneo Studio versions has been reshaped to introduce a simplified Try Out panel in the main Studio window and a completely new advanced Try Out window.

The Try Out panel allows users to test inputs quickly, but when the user needs to view further information, such as the details related to annotations, processing path, or the state of watched variables, all of this information and much more is now available only in the Try Out window.

On top of this, the processing path of the Try Out has been updated to cater for the Match Requirements and Data Actions and obsolete elements have been removed.

Match Requirements listed in the Path view of Try Out

The time stamp in Try Out is now also localized using the solution's language to generate the format.

Learn more

Flow graph and panels

The Flow window has been modified to create better visibility of information and to ensure better functionality of panels in the Flow window.

The Flow graph now includes a Flow Overview in the top left area of the view which allows the user to see the overview of the Flow graph while zooming in on a specific area or node.

Flow Overview

The panels, known from former Teneo Studio versions where information was spread in multiple right-side panels, are now displayed in a single scrollable, and resizable column in the right-side of the Flow window, where clicking the side-buttons will automatically take the user to the selected section.

The new panel display gives the user the advantage of only having to manage the division of space between the main view and one panel; so when clicking a new section no new panel opens leading to resizing of the Flow graph which was the case in former Teneo Studio versions, but rather adds more information to the already opened panel, avoiding the automatic resizing of the window display and keeping focus on the sections already selected by the user.

The right-side panel can be resized as known from former Teneo Studio versions, and both the panel to the left and the one to the right will stay the same size when the user clicks around the Flow graph, i.e. selecting a different node, unless of course the user chooses to resize the panels, resize the entire window or close the Flow.

Syntax highlighting and Indents

Syntax highlighting within Groovy and TQL editors to show syntactical errors in scripts and queries within Studio has been implemented as well as more IDE-like support for indenting blocks of code within editors.

TQL highlighting

The work involves:

  • Adding syntax highlighting for Teneo Query Languages queries in the Log Data Source window
    • Highlighting of keywords, operators and strings
    • Auto-completion for basic query commands
    • Highlighting of invalid commands
  • Improved support for Groovy syntax in script editors
    • Better support for different identifiers (type names, literals, keywords, etc.)
    • Improved / (slash) highlighting
  • Ctrl+F allows to find in script and condition editors
  • Tab and Shift+Tab allows to indent and outdent in script and condition editors.

Read more on scripts in the Knowledge Base

Spell check

Support for spell checking within relevant fields in Studio. Highlighting where errors have been made ensures users are pushed to fix earlier in the cycle - reducing load on testing and preventing errors.

The spell check uses the solution language and Windows language packs, as such the spell check is enabled whenever the language pack for the current solution language is available.

Learn more in the User Guide

A note on HTML

As part of the above work, the Answer and Resume prompt fields on Output nodes have been converted from a simple-HTLM-aware control to a plain text box; text in the Output node will be interpreted (and highlighted) as Groovy when ${...} is detected in the text box.

Answer rotation in Output nodes

The selection and rotation of answers in the Output node have changed from previous Teneo versions. The answer selection is now random per default when more than one answer is provided in the Output node. Answers can still be ordered when the user defines it this way; when the order is defined please note that the answers will be given in order until the last one which will then be repeated. An option to cycle the answers has been added, and if this is selected the answers will be given sequentially, starting from the first one after the last.

This change will be a functional change for solutions on migration - any answer / resume prompts which are currently set to order randomly will have a fallback - so solutions of prior versions will give the last answer repeatedly once the others in the list have been given.

After migration these solutions will behave differently in that the answers will be given randomly forever, no "final answer" will be given. If this fallback behavior is really required then a transition counting approach will be needed to redirect the user to a different output with the "fallback" answer when X answers have been given.

Read more

Folder Browser displays objects from lexical resources

When working with Language Objects and Entities in for example Match Requirements, the Folder Browser window, which allows to browse to a specific folder to find specific objects now not only allows to browse the objects available in the current solution but also the folders and objects available in lexical resources.

This means that user will now easier be able to locate Language Objects and Entities residing in, for example, the Teneo Lexical Resource assigned to the solution.

Folder browser displays assigned lexical resources

Entity Variable propagation

Variables will be automatically included to be propagated when they exist both in the parent Entity and the Entity referenced in the entry.

  • A new referencing entry is added to the parent - any matching variable will be propagated
  • A new variable is added to the parent - any referencing entry with matching variables will be propagated


  • CITIES Entity contains a city_code variable
  • A new SPECIAL_CITIES Entity / Language Object is added - which has a city_code NLU Variable
  • In the Entity CITIES a reference to the SPECIAL_CITIES Entity / Language Object is added
  • The editor now detects the city_code variable on the SPECIAL_CITIES Entity / Language Object and adds the lob.city_code propagation script to the variable cell

Automatic Entity Variable propagation

Learn more about Entities and NLU Variables

Support for solution imports

The support for solution imports has been reviewed:

  • To avoid users trying to import newer solutions into older versions of Studio with the risk of losing data, Teneo Studio now doesn't allow for imports of solutions from environments with a higher/newer version than the current.
  • Import of solutions from the Teneo Studio versions 2 and 3 has been deprecated and is no longer supported. Import of solutions from Teneo Studio 4.2 onwards is still supported.

Further improvements

Apart from the main new features presented above for Teneo Studio 6.0 work has also been performed to improve behaviors or features from former Teneo versions described in this and the following sections; including ensuring stability of Teneo Studio and correcting use cases which could cause crashes of the frontend in addition to ensuring that, when relevant, messages are logged correctly and error messages displayed to the user.


  • A bug in Teneo 5.1 where two exceptions would often appear in logs, one due to Engine start failure and another displaying a license error has been corrected.

UI messages

Several of the descriptive texts and (error) messages in Teneo Studio have been reviewed to provide the users with clearer and easier understandable messages, including among others:

  • When a user tries to delete a solution which is opened by another user, the first user is now prompted with a solution is locked message to avoid deletion of a solution in use.
  • Review of descriptions in the Classifier, including adding the descriptive messages to the drop-down chooser combo.
  • The warning message displayed in Try Out when Engine detects Listeners with equal ordering now propose checking the solution's Suggestions.
  • The error message produced by Learn when all examples of a Class contains less than 4 characters should now convey more coherent information to the user.

Missing documents

The messages in Teneo Studio related to invalid, missing or disabled Language Objects and Entities used in Match Requirements and Data Actions has been implemented.

Special attention has been on Localization setups where the user can now select which documents to branch to Local solutions to ensure that if a Flow is branched to a Local solution, but a Global Variable / Scripted Context / Class / Language Object / Entity used by the Flow as either a Match Requirement or a Data Action isn't included in the branching, the user will obtain suggestions for both Intent Triggers and Transitions to bring attention to these missing elements.

Learn more about missing elements and broken references in the User Guide


  • The save action required, when for example uploading a resource, in the former Teneo Studio version left the save button still active, which could cause the user to click save several times although not needed. Therefore, the save action of Teneo Studio has been reviewed and enhanced to ensure correct behavior and to avoid unnecessary save actions to run in the background.
  • The export of resources - or libraries - from Teneo Studio has been revisited after finding some inconsistencies which have been corrected.
  • In a solution with file resources it is now again possible to edit these, export and re-import the solution as new, as well as publishing it.

Bulk Import

The Bulk Import functionality has been reviewed to ensure correct functionality, especially with a focus on the new Match Requirements and the option to bulk import Q&A Flows.

  • When neither a Condition Match Requirement nor a Class Match Requirement is specified in the import file, an Intent Trigger will still be created (without any defined Match Requirements) and labeled with the newly introduced "TODO" label
  • NLU Generator is no longer available on Bulk Import.

NLU Generator

  • The NLU Generator button (available in Condition Match Requirements, under Advanced) has been renamed to Draft Condition and now displays an informative message to the user while generating the condition. The Draft Condition button is only enabled when one or more examples are added to the Intent Trigger/Transition.
  • The selection of Language Objects and Entities located in the solution versus objects located in assigned lexical resources has been aligned ensuring that both Language Objects and Entities in the solution are priorities over objects from an assigned lexical resource.
  • The NLU Generator no longer selects an Entity if this contains stopwords as entry values or the same single word in all examples.


  • The Suggestions functionality has been reviewed with a special focus on those suggestions related to Classes available in a solution to improve the performance and furthermore, now suggestions compare only the original examples and not the normalized examples.
  • A suggestion is now generated if an Intent Trigger contains a negative example which is also present as training data in the Class of the assigned Class Match Requirement.
  • The suggestion "Node has only "Conditional, Continue" transitions" is now displayed correctly when a Flow in the solution contains a node with only conditional, non-input consuming transitions leaving the node.
  • No suggestions are created for documents that are in the new Recycle Bin.

Flows, Language Objects and Entities

  • A UX improvement, when choosing to Edit from a Flow / Language Object / Entity which the user has open in Read-only mode and another user has open in Edit mode, has been implemented, resulting in the lock being reported to the user and the document being reopened in Read-only.
  • An bug where the error message "A flow link node is linked to a non-sub-flow and has post transitions" would be displayed erroneously in a Flow has been corrected.
  • The Listener of a Flow in read-only mode is no longer editable.
  • A navigation issue when restoring a previous version of a Flow has been fixed.
  • The Condition Building Assistant (Ctrl+space) in the Condition editor has been revisited to ensure correct behavior after detecting a bug in Teneo Studio 5.1.2.
  • Japanese and Chinese characters are now displayed correctly in Entity string variable values.
  • A bug in Localization setups implying not being able to save a local flow without applying Master changes to linked integrations/Flows has been fixed.
  • Navigation to Language Objects, Entities, and Classes has been aligned in the Condition editor and the Match Requirements to Ctrl + left click access to the referenced objects.


  • When creating a Publishing environment, the drop-down menu for selecting the Log Archive now displays the log archive Id, and the copy action button copies the log archive Id to the clipboard.

Indonesian language code update

  • The language code for Indonesian (id) has been aligned in Teneo Manager and Teneo Studio.