Scenario package
The kiosks and automation devices in our solution are designed to accept and execute user-defined scenarios. However, this functionality is conditional on the activation of the SCENARIO capability and the use of the SCENARIO_EXECUTE mode.
The SCENARIO capability enables kiosks and automation devices to execute pre-configured scenarios, providing greater flexibility to meet specific user needs. These functionalities are available only on devices equipped with this capability and mode.
When the SCENARIO capability is activated, the SCENARIO_EXECUTE mode allows the execution of defined scenarios. This mode must be explicitly enabled for the kiosk or automation device to process and execute scenarios based on the specified parameters.
Structure
A scenario is a ZIP archive containing :
- Structure files (graph) that define the logic and flow of the scenario.
- Images and other assets that include graphical and design elements for display on the kiosk or automation device.
An API is available to generate an empty ZIP archive, providing a predefined structure that can be used as a starting point for scenario creation.
flowchart LR
archive.zip-->scenario.json
archive.zip-->audios
audios-->AUDIO["*.mp3"]
archive.zip-->images
archive.zip-->videos
videos-->VIDEOH["horizontal-*.mp4"]
videos-->VIDEOV["vertical-*.mp4"]
images-->AA["horizontal-*.(jpg-png)"]
images-->AB["vertical-*.(jpg-png)"]
images-->thumbnails
thumbnails-->horizontal.png
thumbnails-->vertical.png
style archive.zip fill:#f9f,stroke-width:2pxScenario
The scenario.json file is a key component of a scenario archive. It serves as the main configuration file that defines the structure and behavior of the scenario. This file typically includes:
- Graph Definition: Specifies the sequence of steps, conditions, and transitions within the scenario.
- Metadata: Contains general information such as the scenario name, version, and description.
- Theme Configuration: Defines the visual theme, including colors, fonts, and UI elements, ensuring a consistent user experience.
- Engine Version: Specifies the version of the scenario execution engine required for compatibility and proper functioning.
- Asset References: Links to images, sounds, or other resources used within the scenario.
- Execution Parameters: Defines settings and rules for how the scenario should be processed by the kiosk or automation device.
This file ensures that the scenario is properly interpreted and executed according to the defined logic, while maintaining consistency with the execution engine and design guidelines.
{
"engine": {
"version": "1.0.0" // (1)
},
"metadata": {
"name": "Black Friday",
"description": "Operation black friday long description",
"version": "5.0.1"
},
"scenario": {
"enabled": true,
"openingHours": [],
"theme": {} // (2)
"steps": [] // (3)
"resources": []
}
}
- Scenario engine version for execution.
- Theme, see theme section
- Steps, see steps section
| Field | Description | Type | Value |
|---|---|---|---|
| engine.version | Specifies the version of the scenario execution engine required for compatibility and proper functioning. | Enumeration | 1.0.0 |
| metadata.name | Scenario name | String | |
| metadata.description | Scenario description | String | |
| metadata.version | Each time a scenario is updated, a new version will be created to ensure full traceability and easy rollback if needed. | String | |
| scenario.enabled | if enabled is set to true, the scenario will be automatically activated right after being pushed. | Boolean | true or false |
| scenario.theme | Defines the visual theme, including colors and borders ensuring a consistent user experience. | Json | Theme section |
| scenario.steps | Scenario steps. | Json | Steps section |
| scenario.resources | Scenario resources (eg: tickets). | Json | Resources section |
| scenario.openingHours | Scenario opening hours | Array | Opening Hours |
Danger
If a scenario is pushed again with the same version number, it will be overwritten, making any rollback impossible.
Generate archive quickly
An API is available to generate and download a generic scenario archive in ZIP format. This archive contains the skeleton files required to initialize a new scenario for a specific company. The API is designed to facilitate the quick creation of ready-to-use scenarios based on a standardized structure.
Access Swagger API documentation
Theme
Defines the visual appearance of the scenario, including:
- Light and Dark Mode: The interface adapts automatically based on ambient lighting conditions. When visibility is low in the room where the kiosk or automation device is located, the dark mode is applied automatically.
- Border Styling: Specifies border radius settings for containers and buttons, ensuring a modern and user-friendly design.
{
"scenario": {
"theme": {
"light": {
"primary": "#B33B15",
"secondary": "#B88576"
"tertiary": "#A58F44",
"error": "#FF5449",
"success": "#008000",
"warning": "#ff8000",
"neutral": "#998E8C"
},
"dark": {
"primary": "#B33B15",
"secondary": "#B88576"
"tertiary": "#A58F44",
"error": "#FF5449",
"success": "#008000",
"warning": "#ff8000",
"neutral": "#998E8C"
},
"border": {
"radius": 15
}
}
}
}
| Field | Description | Type |
|---|---|---|
| scenario.theme.light | Light mode theme | Json |
| scenario.theme.light.primary | Primary color for call to actions and primary containers | String (hexadecimal) |
| scenario.theme.light.secondary | Secondary color for simple button and secondary containers | String (hexadecimal) |
| scenario.theme.light.tertiary | Tertiary color for minor information bloc | String (hexadecimal) |
| scenario.theme.light.success | Color for success messages | String (hexadecimal) |
| scenario.theme.light.warning | Color for warning messages | String (hexadecimal) |
| scenario.theme.light.error | Color for error messages | String (hexadecimal) |
| scenario.theme.light.neutral | Color for main background | String (hexadecimal) |
| scenario.theme.dark | Dark mode theme, same as light mode green |
Json |
| scenario.theme.border | Borders | Json |
| scenario.theme.border.radius | Containers and buttons radius | Integer |
Steps
This section describes the generic structure of a JSON file used to orchestrate an interactive journey based on successive steps. This type of structure is commonly used in scenarios such as dynamic user flows, interactive form systems, or digital contests. Each step is defined by a set of properties that determine its content, triggers, and transitions to other steps.
General Structure
The JSON file is organized as an array of steps, where each element represents a distinct step in the journey. Each step contains the following attributes:
- id: A unique identifier that allows referencing this step in transitions.
- type: Describes the type of content displayed (e.g., HTML, PAYMENT, etc.).
- triggers: A list of events that activate the display or execution of the step.
- content: Contains the necessary information for display, including HTML, CSS, or other resources.
Triggers
Triggers activate a step when certain conditions are met. These could include user interactions such as opening or closing an interface, clicking an element, successfully submitting a form, or automatic transitions after a set delay.
Transitions and Navigation
The jumps attribute defines the transition rules between steps, based on user interactions or predefined timing. Common transition types include:
- Conditional navigation: Based on a specific action (e.g., clicking, validation).
- Automatic navigation: Occurs after a set delay or particular event.
- No transition: A step may not have an explicit transition, keeping the user in place until an external action occurs.
{
"scenario": {
"steps": [
{
"id": "display-welcome-picture"
"type": "HTML",
"description": "Display welcome picture",
"triggers": [{
"type": "ON_OPEN",
"content": {}
}],
"jumps": [{
"type": "ON_DELAY",
"content": {
"delay": 6000
},
"target": "next-step-id"
}]
"content": {
"html": "<div>Screen content in HTML format",
"css": null
}
}
]
}
}
| Field | Description | Type | Values |
|---|---|---|---|
| scenario.steps | List of steps | Array | |
| scenario.steps.id | Step unique id | String | |
| scenario.steps.description | Human description for debug | String | |
| scenario.steps.type | Step type | Enumeration | Steps catalog |
| scenario.steps.triggers | Step triggers - step specific | Array | Steps catalog |
| scenario.steps.jumps | Jumps - step specific | Array | Steps catalog |
| scenario.steps.jumps.type | Jumps type | Enumeration | Steps catalog |
| scenario.steps.jumps.target | Next step id | String | |
| scenario.steps.content | Step content | Json | Steps catalog |
Example of scenario
flowchart TD
A["When scenario engine is ready"] -- CHECK --> Z["Check opened hours and if enabled"]
Z -- ON_CLOSE --> B["Display image scenario closed"]
Z -- ON_OPEN --> C["Display image scenario opened"]
C -- ON_CLICK --> D["Ask final user personnal informations (firstname, lastname, email, etc...)"]
D -- ON_SUBMIT --> E["Display image to thank"]
E -- ON_DELAY(8000ms) --> A
style A fill:#ffcccc,stroke:#333,stroke-width:2px
style B fill:#ffeb99,stroke:#333,stroke-width:2px
style C fill:#ccffcc,stroke:#333,stroke-width:2px
style D fill:#ccffcc,stroke:#333,stroke-width:2px
style E fill:#ccffcc,stroke:#333,stroke-width:2pxCatalog
To clarify, the steps in this JSON structure can belong to different types, allowing for a flexible and modular system. A catalog of step types typically exists to define and standardize how each step behaves.
| Type | Description | Step | Resource |
|---|---|---|---|
| HTML | To display HTML page | Steps - HTML | Assets - Form |
| To perform a print | Steps - Print | Ticket |
HTML
The HTML type is one of the most flexible and commonly used. It allows the display of custom HTML content, including texts, images, forms, or any other web component, in order to create interactive and engaging user experiences.
Triggers
| Trigger | Description | Content |
|---|---|---|
| ON_OPEN | When scenario start | |
| ON_CLOSE | When scenario close |
Content
This JSON example represents a simple interactive scenario designed to be executed on a kiosk or interactive terminal. The scenario is composed of a single step, which displays a welcome screen with a call-to-action button to start the next action (e.g., a game, contest, form).
{
"scenario": {
"steps": [
{
"id": "display-welcome-picture"
"type": "HTML",
"description": "Home screen when kiosk is open",
"triggers": [{
"type": "ON_OPEN",
"content": {}
}],
"jumps": [{
{
"type":"ON_CLICK",
"content": {
"target": "call-to-action-button"
},
"target": "next-step"
}
}]
"content": {
"html":"<div class=\"h-screen\" style=\"background-color: white\"><img src=\"135\"><button id=\"call-to-action-button\">Start the game</button></div>",
"css": null
}
}
]
}
}
| Field | Description | Type | Value |
|---|---|---|---|
| content.html | HTML content | String (HTML) | |
| content.css | Add extra css | String (pure css) |
Jumps
| Jump type | Description | Content |
|---|---|---|
| ON_CLICK | Final user click on a HTML element | {"target": "id-of-html-element"} |
| ON_DELAY | Jump automatically after a delay | {"delay": 5000} |
| ON_SUBMIT | When a form is submit | {} |
Device capability
As of today, all devices that accept a scenario are systematically equipped with the SCENARIO capability and support SCENARIO_EXECUTE mode. Therefore, this type of HTML step is guaranteed to be executable as soon as a screen is available on the device.
| Capability | Mode | Datasheet |
|---|---|---|
| SCENARIO | SCENARIO_EXECUTE | Scenario |
Dynamic image injection via src
Just like with forms, it's possible to reference images dynamically inside an HTML step by using an tag where the src attribute contains the ID of the image stored in the references.
The engine will automatically fetch the correct image and adapt it to the device orientation (vertical or horizontal) at runtime, depending on the screen.
{
"content": {
"html":"<img src=\"135\" />",
"css": null
}
}
Dynamic form injection via id
Just like images, it is possible to dynamically inject a form inside an HTML step simply by adding a form tag where the id attribute corresponds to the form ID defined in the references. The engine will automatically fetch and render the form fields associated with that ID at runtime, allowing flexible and reusable form management.
{
"content": {
"html":"<form id=\"reference-html\"></form>",
"css": null
}
}
The PRINT type corresponds to an interaction dedicated to managing a ticket or coupon printing process. This step is used when a user needs to receive a physical printout, such as a winning voucher or participation confirmation.
Triggers
| Trigger | Description | Content |
|---|---|---|
| ON_OPEN | When scenario start | |
| ON_CLOSE | When scenario close |
Warning
Normally empty, but could be used to launch the step on specific events. Although it is technically possible to trigger a PRINT step directly at the opening of a scenario, this is generally discouraged in functional scenarios, as it does not allow users to confirm or validate their participation before printing.
Content
{
"scenario": {
"steps": [
{
"id": "print-voucher-ticket"
"type": "PRINT",
"description": "Print voucher ticket",
"triggers": [],
"jumps": [{
{
"type":"ON_SUCCESS",
"content": {},
"target": "print-voucher-ticket-success"
},
{
"type":"ON_FAILURE",
"content": {},
"target": "print-voucher-ticket-failure"
}
}]
"content": {
"html":"<div class=\"h-screen\" style=\"background-color: white\"><img src=\"135\"></div>",
"css": null,
"ticket": "voucher-ticket-resource-reference",
"messages":[
{
"type":"PRINT_PROGRESS_TITLE",
"message": "One moment..."
},
{
"type":"PRINT_PROGRESS_DESCRIPTION",
"message": "Your voucher is being printed"
},
{
"type":"PRINT_SUCCESS_TITLE",
"message": "Printing Complete!"
},
{
"type":"PRINT_SUCCESS_DESCRIPTION",
"message": "Your voucher has been printed"
},
{
"type":"PRINT_FAIL_TITLE",
"message": "Oops !!"
},
{
"type":"PRINT_FAIL_DESCRIPTION",
"message": "An error occurred while printing."
}
]
}
}
]
}
}
| Field | Description | Type | Value |
|---|---|---|---|
| content.html | HTML content, typically to build a background | String (HTML) | |
| content.css | Add extra css | String (pure css) | |
| content.ticket | Ticket resource reference id | String | Resource - Ticket |
| content.messages | Messages for final user | Array (Json) | See next table |
To ensure a smooth and understandable user experience during the printing process, PRINT steps include a list of messages defined in the payload. These messages are designed to inform the user of each key moment of the print process and are fully customizable in terms of content and tone, according to the context (e.g., contest, voucher, reward).
| Type | Description | Example |
|---|---|---|
| PRINT_PROGRESS_TITLE | Title displayed when printing is in progress | "One moment..." |
| PRINT_PROGRESS_DESCRIPTION | Description shown during the printing phase | "Your voucher is being printed." |
| PRINT_SUCCESS_TITLE | Title shown when printing completes successfully | "Printing Complete!" |
| PRINT_SUCCESS_DESCRIPTION | Complementary success message | "Your voucher has been printed." |
| PRINT_FAIL_TITLE | Title shown in case of printing failure | "Oops!" |
| PRINT_FAIL_DESCRIPTION | Error explanation if printing cannot be completed | "An error occurred while printing." |
Jumps
| Jump type | Description | Content |
|---|---|---|
| ON_SUCCESS | Print successful | {} |
| ON_FAILURE | Print failure | {} |
Device capability
To successfully execute a PRINT step, at least one printer must be connected to the system and report a health status of "nominal" or "warning".
- If no printer meets these conditions (e.g., all printers in error state or offline), the print operation cannot be executed, and the system will automatically trigger an ON_FAILURE jump, if defined. This allows redirecting the user to a fallback step (e.g., error screen or alternative solution).
- If multiple printers are connected and operational, a load-balancing mechanism will automatically distribute the printing requests across available devices to optimize usage and reduce wait time.
| Capability | Mode | Datasheet |
|---|---|---|
| PRINTER | PRINTER_PRINT | Printer |
Resources
A scenario's resources are structured files that support the scenario but are not typical images. They can include printable files, data files, forms, or any other structured content required for the scenario's execution. Each resource has an id that allows it to be referenced from a scenario step, and a type that defines its nature and usage.
{
"scenario": {
"resources": [
{
"id": "voucher-ticket" // (1)
"type": "TICKET", // (2)
"description": "Voucher ticket" // (3)
"content": {} // (4)
}
]
}
}
- Unique resource ID
- Resource type
- Description, for debug
- Resource specific configuration
| Type | Description | Value |
|---|---|---|
| TICKET | Printed outputs like gift vouchers, receipts, pickup slips | Resource - Ticket |
| FORM | Form, can be called directly form a | Resource - Form |
Tip
Additionally, all textual content inside resources can leverage the template engine. This means you can insert dynamic placeholders — for example, {{name}} — that will be automatically replaced at runtime with real data collected during the scenario (e.g., from a previous form step).
Catalog
Ticket
In a scenario, a resource can also include a ticket, which is a structured file designed to be printed by printers to illustrate specific outputs such as: a gift voucher, a receipt or Any other formatted printed document generated as part of the scenario flow.
{
"scenario": {
"resources": [
{
"id": "voucher-ticket"
"type": "TICKET",
"description": "Voucher ticket"
"content": {
"lines": [{
"position": 1,
"type": "H1",
"align": "CENTER",
"content": "H1 Title"
}, {
"position": 2,
"type": "H2",
"align": "LEFT",
"content": "H2 Title"
}, {
"position": 3,
"type": "H3",
"align": "RIGHT",
"content": "H3 Title"
}, {
"position": 4,
"type": "P",
"align": "LEFT",
"content": "Paragraph"
}, {
"position": 5,
"type": "LINE",
"align": null,
"content": null
}, {
"position": 6,
"type": "LINE_CUT",
"align": null,
"content": null
}, {
"position": 7,
"type": "IMAGE",
"align": "CENTER",
"content": "image-asset-id" // (1)
}]
}
}
]
}
}
- Id of picture asset, see asset reference section
| Field | Description | Type | Value |
|---|---|---|---|
| position | Line position on ticket (from top to bottom) | Integer | |
| type | Line type | Enumeration | H1 (big title), H2 (medium title), H3 (small title), P (paragraph), LINE (full line), LINE_CUT (cut line), IMAGE (picture in white and black) |
| align | Alignment (not needed when type is LINE and LINE_CUT) | Enumeration | LEFT, CENTER, RIGHT |
| content | Text to print (not needed when type is IMAGE, LINE and LINE_CUT) | String |
Form
Among the available step types in the scenario catalog, the FORM type is used to display and manage interactive forms, enabling data collection, opt-ins, and user consent directly within the scenario flow. This step allows users to fill out information, accept legal terms, and validate their participation in contests, surveys, or marketing operations.
{
"scenario": {
"resources": [
{
"id": "user-main-form"
"type": "FORM",
"description": "Form user registration before play game"
"content": {
"inputs": [{
"position": 1,
"type": "TEXT",
"name": "firstname",
"placeholder": "Your Firstname",
"required": true,
"smallHelp": "Your first name is needed",
"bigHelp": null
}, {
"position": 2,
"type": "TEXT",
"name": "lastname",
"placeholder": "Your Lastname",
"required": true,
"smallHelp": null,
"bigHelp": null
}, {
"position": 3,
"type": "CHECKBOX",
"name": "rules",
"placeholder": "Please read the contest rules carefully",
"required": true,
"smallHelp": "Please read the contest rules carefully",
"bigHelp": "The full contest rules in markdown format"
}, {
"position": 4,
"type": "MAIL",
"name": "mail",
"placeholder": "Your mail",
"required": true,
"smallHelp": null,
"bigHelp": null
}, {
"position": 5,
"type": "PHONE",
"name": "phone",
"placeholder": "Your phone",
"required": false,
"smallHelp": null,
"bigHelp": null
}, {
"position": 6,
"type": "DATE",
"name": "birthday",
"placeholder": "Please enter your date of birth",
"required": false,
"smallHelp": null,
"bigHelp": null
}, {
"position": 7,
"type": "TEXT",
"name": "comment",
"placeholder": "Please let a small comment if you want",
"required": false,
"smallHelp": null,
"bigHelp": null
}, {
"position": 8,
"type": "RADIO",
"name": "favorite_mall",
"placeholder": "Favorite mall",
"required": false,
"smallHelp": null,
"bigHelp": null,
"values": [{
"label": "Urban Loom",
"value": "Urban-Loom"
}, {
"label": "Fresh Fields Market",
"value": "Fresh-Fields-Market"
}, {
"label": "Little Sprout",
"value": "Little-Sprout"
}]
}, {
"position": 9,
"type": "CHECKBOX",
"name": "favorite_mall_checkbox_sample",
"placeholder": "Favorite mall",
"required": false,
"smallHelp": null,
"bigHelp": null,
"values": [{
"label": "Urban Loom",
"value": "Urban-Loom"
}, {
"label": "Fresh Fields Market",
"value": "Fresh-Fields-Market"
}, {
"label": "Little Sprout",
"value": "Little-Sprout"
}]
}, {
"position": 10,
"type": "LIST",
"name": "favorite_mall_list_sample",
"placeholder": "Favorite mall",
"required": false,
"smallHelp": null,
"bigHelp": null,
"values": [{
"label": "Urban Loom",
"value": "Urban-Loom"
}, {
"label": "Fresh Fields Market",
"value": "Fresh-Fields-Market"
}, {
"label": "Little Sprout",
"value": "Little-Sprout"
}]
}]
}
}
]
}
}
| Field | Description | Type | Value |
|---|---|---|---|
| position | Input position on screen (from top to bottom) | Integer | |
| type | Input type | Enumeration | TEXT (free), MAIL (mail check), PHONE (phone number), DATE, RADIO (single choice), LIST (single choice), CHECKBOX (multiple choices) |
| name | The name is the key identifier used when capturing and storing form data | String | |
| placeholder | Guide the user on what kind of information to enter, it disappears when the user starts typing | String | |
| required | The user must fill it out before submitting the form | Boolean | |
| helpSmall | Used to give additional information or guidance about what the user should enter. Unlike placeholders, helpSmall stays visible at all times, even when the user has started typing | String | |
| bigHelp | A help system that displays a popup window when the user clicks on a help icon or link near a form field | String (Markdown) | |
| values | The values attribute is used to define and populate lists of options for form elements like: Dropdown lists (select), checkbox groups, radio button groups (only for RADIO, LIST, CHECKBOX) | Array | |
| values.label | The text displayed on screen to the user | String | |
| values.value | The data stored and sent when the user makes a choice | String |
Tip
Regardless of how you write it (uppercase, lowercase, mixed case), the name will always be converted to lowercase during data extraction. To ensure consistency and avoid confusion, we recommend following this format when defining name values:
- Use only lowercase letters (a-z).
- Separate words with hyphens (-) if needed.
- Add numbers if necessary (e.g., for multiple fields).
Warning
If the same form (same form reference) is used in multiple steps of a scenario, and the user navigates through these steps several times, the collected data will always reflect the latest version of the form submitted.
Directory images
The archive contains a dedicated folder named images, which stores all image assets used in the scenario. The system supports PNG and JPG formats, ensuring compatibility with most graphical elements while maintaining quality and performance.
Directory images/thumbnails
flowchart TB
images-->*-horizontal.jpg
images-->*-vertical.jpg
images-->*-horizontal.png
images-->*-vertical.png
images-->thumbnails
thumbnails-->horizontal.png
thumbnails-->vertical.png
style thumbnails fill:#DB2D43,stroke-width:2px
style horizontal.png fill:#DB2D43,stroke-width:2px
style vertical.png fill:#DB2D43,stroke-width:2pxWithin the images/ directory, there is a subdirectory named thumbnails/, which is specifically reserved for storing thumbnail images. These thumbnails are used when the kiosk or automation device offers multiple scenarios, allowing users to preview and select a scenario more easily.
Orientation-Specific Images:
- horizontal.png: Used for scenarios displayed in landscape mode, ensuring proper scaling and alignment on wide screens.
- vertical.png: Used for scenarios displayed in portrait mode, optimizing the layout for taller screens.
Files under images
flowchart TB
images-->*-horizontal.jpg
images-->*-vertical.jpg
images-->*-horizontal.png
images-->*-vertical.png
images-->thumbnails
thumbnails-->horizontal.png
thumbnails-->vertical.png
style *-horizontal.png fill:#DB2D43,stroke-width:2px
style *-vertical.png fill:#DB2D43,stroke-width:2px
style *-horizontal.jpg fill:#DB2D43,stroke-width:2px
style *-vertical.jpg fill:#DB2D43,stroke-width:2pxUsers are free to add their own images within the images/ directory, as long as they follow the predefined file naming conventions to ensure compatibility with the scenario engine. These custom images can be used for backgrounds, UI elements, or other visual assets within the scenario. The scenario execution system will automatically select the appropriate image based on the device's current orientation, even for user-defined images that are referenced in scenario.json
Asset references and conventions
All asset filenames (images, videos, and other media files) must follow a strict naming convention to ensure compatibility with the scenario execution engine.
Allowed characters in filenames:
- Lowercase letters only (a-z)
- Numbers (0-9)
- Hyphens (-)
Warning
Spaces, uppercase letters, special characters, and underscores are not allowed.
Asset optimisations
It is recommended to use optimized images to improve performance and loading times, especially for devices with limited processing power. Thumbnails should be kept at a reasonable resolution to ensure fast display without unnecessary resource consumption.
- PNG: Best for images with transparency or sharp edges (e.g., icons, UI elements). Use compressed PNGs where possible.
- JPG: Ideal for photos and complex images with gradients, as it provides better compression and smaller file sizes.
Opening Hours
The JSON configuration flow for opening hours is designed to define the periods during which an interactive kiosk is available to users. Each time slot includes a specific opening and closing date and time, expressed in ISO 8601 format. This format ensures minute-level precision and allows for flexible or temporary scheduling. Time slots are independent of each other and can be combined within the same day to represent multiple opening periods (e.g., morning and afternoon). This model does not handle exceptions or special closures — only the time slots explicitly listed in the flow will be considered, and if no time slot is provided for a specific date, the kiosk will remain closed on that day. This structured format is intended to simplify the integration and automatic processing of opening hours by systems connected to the kiosk.
{
"scenario": {
"openingHours": [{
"open": "2025-03-15T08:00",
"close": "2025-03-15T12:00"
}, {
"open": "2025-03-15T14:00",
"close": "2025-03-15T18:00"
}, {
"open": "2025-03-16T09:00",
"close": "2025-03-16T13:00"
}
]
}
}
| Field | Description | Type |
|---|---|---|
| scenario.openingHours.open | Scenario opening date and hour | Date (ISO 8601) |
| scenario.openingHours.close | Scenario closing date and hour | Date (ISO 8601) |
At runtime, if the kiosk is within an active time slot (i.e., between open and close), the ON_OPEN trigger will be fired to activate services or functionalities. Conversely, outside of these time slots, the ON_CLOSE trigger will be fired to deactivate the kiosk and its services.