Dynamic Content and Contexts
Several cells in eva allow you to dynamically build content, from Answers to Gen AI prompts and more. This page will assist you to fully understand eva's capabilities for creating Dynamic Content.
What is Dynamic Content?
Certain fields in eva cells partially comply with JavaScript syntax. This enables you to reference variables anywhere in your content, allowing it to be dynamic.
eva provides a set of available variables that allow you to access user inputs, recognized metadata from the previous interaction, and generated or processed content from other cells. You can insert those variables in your texts preceded by the symbol '$' (dollar sign) and eva will convert their values on the fly during the conversation.
The following example shows how you can use dynamic content to create a customized greetings message, by reading the user's name dynamically during the dialogue.
In this case, the same virtual agent can greet different users by their names, “Hi, Anna”, “Hi, Joe”, allowing the virtual agent to use in the answers the information given by users to eva.
If you write the word 'text' on any field, for instance, it will show exactly as it is. If you write '$text', instead, it will be replaced by the last thing your user wrote on the conversation.
The '$' symbol is required on most cells, unless specified below.
Cells that allow Dynamic Content
The following table illustrates the cells that support Dynamic Content in eva and the associated set of fields that empower you to use this feature.
| Cell type | Fields that allow Dynamic Content |
|---|---|
| |
| |
| |
| |
Code cells can use all Dynamic Content features, but with a distinct text notation: it doesn't require the '$' character preceding variables. Refer to its page for more examples. | |
Like in the Code cells, Rule cells can use all Dynamic Content features, but with a distinct text notation: doesn't require the '$' character preceding variables. Refer to its page for more examples. |
If you're familiar with coding, you can write more complex structures, such as conditional clauses and text operations on those fields as well.
Please note that, as a rule of thumb, those cells and their fields are read-only. This means that any content you write to variables will not persist to the next cell, unless specified otherwise.
To predict different answers to different variables and parameters, you can use Answer Cells as a printing tool for development purposes.
Dynamic Content execution in eva uses the The Apache Velocity Project. Refer to its page for notation and code structure.
Supported variables
Besides the default variables, eva has 3 separate contexts which are, essentially, variable holders for you to store anything you wish during a conversation.
Data stored on those variables will persist between flows and are session-exclusive, meaning any value attributed to a conversation only exists there. They are as follow:
| Variable | Function | Syntax/Notation |
|---|---|---|
Intents | Stores the last recognized intents, most accurate first and least accurate last, in a list. | $intents[0] (Obs.: The formula remains unchanged regardless of the Intent's name) |
Entities | Stores the last recognized entities, in a list. | $entities['entity's_name']['0'] |
Text | Stores the last text sent by the user | $text |
Information about the virtual agent (bot) | Contains the virtual agent name | $info.bot |
Information about the channel | Contains the given name for the currently used channel | $info.channelName |
Information about the channel type | Contains the current channels type (whether its web, Facebook, Alexa, etc.) | $info.channelType |
Session Code | Contains the UUID/GUID of ongoing conversations. It's empty before user's first input. | $sessionCode |
Code | Stores the code of the last message (unprocessed, raw input). | $code |
Parameter | Contains the parameters you have setup in eva - both virtual agent parameters and environment parameters. In the event that there is a parameter with the same name in both lists, the bot parameter will take precedence. Learn more about Parameters | $parameters['parameter's_name'] |
Store user-defined variables, with distinct readability rules. | $openContext.field $visibleContext.field $hiddenContext.field |
All of the variables listed above, save for the contexts, are read-only attributes. That means you cannot edit their content.
Sub-variables
Some of the variables above have nested variables, i.e., variables within themselves. See the examples below:
Intent
| Variable | Function | Formula/Notation |
|---|---|---|
Name | Name of the intent, same as the NLP. | $intents[0].name |
Confidence | Confidence score returned by the NLP, this will be a percentage number from 0 to 1. | $intents[0].confidence |
Entity
| Variable | Function | Formula/Notation |
|---|---|---|
Name | Name of the entity, same as the NLP. | $entities['entity's_name']['0'].name |
Value | The value of the entity returned by the NLP | $entities['entity's_name']['0'].value |
Position | Position of the string within the user input (text) | $entities['entity's_name']['0'].position |
Entities and intents nested attributes are read-only. That means you cannot edit their content.
eva's Contexts
As a chatbot developer, one may find it difficult to keep track of different variables while maintaining the context and natural flow of a conversation.
eva helps you capture and reuse contextual data for a large variety of scenarios, so you can create more complex use cases and redefine the enterprise customer experience, through the context variables.
The context's saved data is only available during the session, meaning that it is lost when the session code expires.
All contexts coexist throughout the conversation. Because they are the only way to store your custom variables, it is expected that each context will contain several nested variables (sub-variables), as illustrated below:
$openContext.yourVariable
$openContext.yourVariable.subValueA
$openContext.yourVariable.subValueB
$openContext.yourOtherVariable
[etc...]
Understanding how the context works is one of the most essential parts of eva. It is possible to use 3 different types of context: open, visible and hidden.
Open context
Shared in all integrations and can be modified by anyone. Channels that integrate with eva are considered insecure and this is the only place where they can manage information in eva’s context.
Important: Don’t store sensitive data in this context. This information can be accessed and modified by external agents, such as channels.
If you are integrating with third party channels, you may need to use this context if you want your channel to access and also modify a variable, but you should only do so when strictly necessary. We encourage you to modify eva's variables with it's tools, such as Code and Rest Connector cells, instead.
Visible context
The visible context is available for everyone, but channels are not able to change its content. It is essentially a read-only public context. Information that might be used by the channels but also impacts the conversation flow, service calls and overall functioning of the virtual agent must be added here.
Important: Don’t store sensitive data in this context. This information is visible – but not modified by – external agents, such as channels.
Hidden context
The most secure out of the three. The hidden context is only visible - and editable - by eva’s platform cells, such as Service, Gen AI and Rest Connector cells.
Any content executed by eva on any channel can access data stored here. The integrations and channels themselves are those which have their access restricted.
Important: If there is any sensitive data that needs to be managed in eva, this is where it must be stored.
Storing data on eva Contexts
There are several variables you may use cooked directly into eva, as abovementioned. Besides that, you can store and read data on the three available contexts which are, essentially, variable holders for you to store anything you wish during a conversation.
Context variables can have data stored into them through specific cells, as follows:
| Cell | Can store... |
|---|---|
Every Input cell has a "Remember Input" switch. By enabling it and naming a variable, that current user input is stored as-is in the Visible Context under that variable name. | |
Can read, create and modify existing variables in all contexts without any restrictions. Any code you execute or validation you perform may store their results on persisting variables within any of the three contexts. They can be used to parse existing values in contexts and update them or save data on new fields.
e.g.: | |
The Gen AI cell has a mandatory naming field called "Variable". On execution, the generated content is stored in a variable of that name in the Hidden Context. | |
The Rest Connector cell has a body field like in the Code cell, called Output. This field can perform any operation that a code cell could. Additionally, the result of the Web Request can be found, as received, in the Hidden Context under the name "RestConnectorResponse".
|
Note that none of the tools above store any data in Open Context by default, and only Input Cells store data into Visible Context - because user input is something the your channels already have access to.
Be aware that:
While you can use those contexts if a channel requires to, we strongly advise you to never store any information that a channel should not have access to otherwise - especially sensitive content - unless strictly necessary.
By storing any data on Visible or Open Contexts, you are willingly sharing said information with any third party channel and platform you integrate with.
By storing any data on Open Context, their value is editable by your integrated third party channels and platforms.
Avoiding unnecessary data sharing
If you are integrating with a specific channel or platform that requires access and/or modification of your variables, but also have channels that do not require so, you may wish to avoid having that data shared with your other unrelated channels.
You can use Rule cells and filter the $info.channelName or $info.channelType to ensure that said data is only stored and used on a branching path specific to the required channels.
