Data in Studio
The use and manipulation of data in Studio can be extended depending on the editor you are building in. Each editor implements its own mechanisms to define, access, and transform information, whether through tokens, variables, or other forms of temporary persistence.
This section aims to present basic definitions for managing data in Studio, tokens segmentation, and the main characteristics of data management in Studio editors, identifying their specificities, limitations, and methods of interoperation. This helps understand the current landscape and lay the groundwork for establishing best practices.
Important
This section focuses exclusively on data handling within Studio and DevTools. It does not cover other consoles on the platform, such as HCMS, BRMS, etc.
Data Fundamentals
A token is the fundamental unit for managing and exchanging data. Its main function is to contain and exchange information between the different entities of the app: processes, screens, modules, or external integrations. Although the system doesn't define strict data types, tokens allow you to manage a wide variety of content, such as numbers, text, boolean states, lists, and more.
In Studio, data is managed using two main types of tokens:
Registers: Simple, untyped structure that stores a single value.
Arrays: Two-dimensional structure (table). Unable to identify column names.
Each token is identified by a unique number within a range of 1 to 999,999. This numeric ID is subject to a predefined segmentation, which not only organizes the tokens by ranges, but also determines specific behaviors (e.g., persistence). Read Segmentation for more information.
Important
The same number can represent two different tokens if they correspond to different types (for example, Register 1 and Array 1 are independent of each other).
For ease of use, there is an alias functionality, which allows you to assign an alphanumeric name to a numeric token. This association must be configured manually, and allows to reference tokens by name instead of number in editors such as the lambda processes editor or the screens editor.
A pseudo-functional classification can be established regarding the use given to tokens in construction, which is key when designing clear, reusable, and loosely coupled solutions:
Information tokens: These are used to capture, transport, and display data, such as user input, process results, or information from external services.
Behavioral tokens: These are used to modify the behavior of components, for example, showing or hiding a section, disabling a button, or changing the navigation flow based on a condition. Some also control the overall flow of the application.
While Studio does not enforce a typing system, it is possible to apply formatting to values when they are displayed on a screen. This allows, for example, dates or coins to be represented with a specific appearance.
Important
Note that the application of the format does not imply prior validation of the content, so its correct use is responsibility of the developer.
As for internal representation, numeric values in Studio follow a convention of type N+XXX. For example, the number 4.65 is represented as 2+465. The following sections will detail how the various Studio editors extend the basic token manipulation capabilities.
Segmentation in Studio
Studio uses a numerical convention to identify tokens throughout the platform. This numbering not only serves an identification function, but also determines the behavior and scope of each token within the application.
The platform establishes specific ranges that define key aspects such as: See the table below to learn about token ranges within the platform and their scope within the app.
Scope | Segment | Range | Description |
|---|---|---|---|
Global | Reserved | 1-499 | Their use is specified by the Platform |
Global | Free use | 500-899 | Can be used freely |
Global | Persistent | 900-999 | Allows assigned values to be stored in the channel even when the app is closed |
Context | Free uso | 1000-799999 820000-999999 | Data varies by functionality |
Context | Image | 800000-819999 | They are used for images storage |
Data in Editors in Studio
In the Screen editor, while there is no strict typing system, some components—such as Text Input—allow you to configure attributes that influence the type of data that will be captured and stored in its corresponding token.
One of the most relevant is the type attribute. This attribute defines the type of data the user will enter (e.g., text, number, email), which impacts both the behavior of the component and how the information is validated and saved. While this setting doesn't enforce a data type internally in Studio, it does serve an important purpose in user experience and basic input validation.
Below is a table showing the available type values and their expected behavior.
Type | Description |
|---|---|
calendar | |
date | It is a calendar to select a date. This calendar allows you to choose a date visually, without having to write the date. The Date Mask attribute allows you to define the format in which the value stored in the token is formatted. |
dateRange | |
url | |
number | |
file | |
timePicker | Displays a window that allows the user to define a time. The Format Time Picker attribute allows you to define the time format (12h or 24h). The 24h date is saved as hh:mm while 12h is saved as hh:mmAM or hh:mmPM. |
rutChile | Validates that the content complies with the Chilean Rut format |
text | Single-line text fields display only one line of text. They are not suitable for collecting long responses. For those, use a multi-line text field or text area instead. |
textMultiline | Allows multi-line functionality. Multi-line text fields display all user input at once. Overflow text causes the text field to expand (shifting the screen elements down) and the text to wrap onto a new line. |
mask |
Although tokens in Studio are untyped structures, Lambda incorporates a model that assumes certain data types, allowing for more precise and controlled work.
String: Represents character strings such as names, descriptions, or addresses.
Number: Represents numeric values, both integers and decimals. It should be noted that Lambda uses decimal notation in Lambda. The “register number” block accepts decimal notation or Veritran (VT) notation. In the latter case the value is automatically converted to decimal notation.
Boolean: Represents a value of true or false.
Lists: Represents an ordered collection of elements of the same type. It should be noted that array is a particular case of list, structured as a list of lists.
Objects (JSON): Currently the only implemented object is JSON. Represents a data structure composed of key-value pairs.
The Modules interface allows you to define the list of data that is received as input and returned as output when such module is invoked.
In the inputs it is possible to specify the type of data expected. This configuration defines the data type and also clearly documents what you expect to receive, improving the maintainability and understandability of the solution.
The allowed types and their implications are listed below.
Type | Description |
|---|---|
text | |
number | |
color | When a configurable component that uses this type of data is configured on a screen, the right panel of the editor will allow a color selection (color picker). The value will be stored in the associated token, in hexadecimal format (for example, #FF5733). |
image | When the module is configured on a screen, the right panel of the editor will allow for image exploration and selection (image explorer). |
text area | |
boolean | The input represents a true or false condition. It can be entered directly as true or false, or by using a Boolean expression that results in one of these values. If the parameter is left empty or set with an incorrect expression, it will be interpreted as false. |
array | For this type of input, a token of type array must be configured in the entity that invokes the module. |
In the case of outputs, the interface only allows defining tokens of the register type, without the possibility of specifying a data type.
The technical definition of an interface—including how inputs, outputs, and invocation conditions are configured—is detailed in Docs documentation here.