What is a Form in tSM?
Forms in tSM are not merely UI screens — they are metadata-driven constructs that bridge the user interface, data model, and runtime behavior within the tSM platform. Their role extends far beyond simple data entry.
Core Purpose
A form in tSM serves two key purposes:
- User Interface Construction: It defines how fields are laid out, grouped, and rendered in the frontend.
- Entity Model Extension: It allows dynamic extension of entity data (via Characteristics) without schema changes.
Thus, forms serve both presentation and data modeling functions — enabling deep customization of the UI and underlying data structures for entities like Tickets, Customers, or Orders.
Where Forms Live in tSM
Forms are part of a broader configuration ecosystem and are typically linked to:
| Element | Role |
|---|---|
| Entities | The core data models (Ticket, Customer, Order, etc.) |
| Characteristics | Custom fields attached dynamically to entities |
| Configuration Profiles | Define which forms and fields are available per entity profile |
| Processes / Logic | Automations and backend flows connected to the form runtime |
Every form is attached to an entity through its Configuration Profile (Enity Specification in TM Forum specification) and loaded via a form selector such as tsm-customer-detail.
Key Components of a Form
Each tSM form is composed of multiple layers:
| Layer | Description |
|---|---|
| JSON Schema | Describes the structure of the form — fields, layout, validation |
| Widgets | Individual UI elements (e.g., text inputs, dropdowns, listings) |
| Layout Components | UI containers (e.g., tabs, cards, columns) that group fields |
| Runtime Logic | Expressions using JEXL for dynamic behavior (e.g., visibility, defaults) |
| Bindings | Links between UI and entity data via chars and entity properties |
| Context Variables | Provide runtime context: $context.form, $context.entity, etc. |
Design-Time vs Runtime
Forms in tSM operate in two distinct contexts:
| Context | Description |
|---|---|
| Design-Time | Form is edited in the Form Designer. Static values only. |
| Runtime | Form is rendered in live UI. Full access to $context, real data, scripts |
Important note: Certain expressions or logic (e.g., $context.form.customerType) will not work in Design-Time and must be tested in the live environment.
Form Types
Forms in tSM can appear in several UI contexts, depending on their purpose:
| Type | Description |
|---|---|
| Dashboard | Widget-based form embedded in dashboards. Used for summaries, charts, or data overviews. |
| Dialog | Modal pop-up form, typically used for entity creation. |
| Page | Full-page form used for displaying/editing entity detail (e.g., Ticket, Customer). |
| Form | Generic embedded form; used in custom tabs, panels, or widgets. |
| Custom Field | Deprecated inline characteristic editor. |
Form type determines rendering context, but layout/configuration principles remain the same. The configuration and layout mechanisms remain the same across all types — only the rendering context changes.
Summary
Forms are dynamic, versioned, configuration-layer elements that:
- Render UIs using JSON Schema, Layout, and Widget definitions
- Extend entity behavior through dynamic fields and logic
- Enable conditional behavior using scripting (JEXL/SpEL)
- Operate across both static (design) and dynamic (runtime) contexts
They are one of the most flexible and powerful tools in tSM — forming the core of how data is entered, visualized, and transformed in the system.