Skip to main content

Key Concepts and Relationships

To work effectively with forms in tSM, it's essential to understand the key building blocks and how they relate to each other. These concepts form the foundation for both simple and advanced use cases.

Entities

Entities are the core data models in tSM — such as Ticket, Customer, Order, User. Each entity can have one or more forms associated with it, depending on its Configuration Profile and UI context.

Characteristics

Characteristics are dynamic attributes used to extend the data model of an entity without modifying its base schema. They are stored under the chars object and can represent custom fields, configuration values, toggles, or selections.

Each characteristic is defined with metadata such as:

  • subtitle: user-facing label
  • name: internal key
  • readonly / editable: permission flags
  • form: selector of the form where it's used

Characteristics are automatically pulled into the Form Designer when a configuration profile is loaded. TM Forum Entities & Characteristics

Configuration Profiles

Configuration profiles act as blueprints for how a given entity is extended and displayed. They define:

  • Which characteristics are available
  • Which forms are attached and how they are used
  • Entity-specific configurations such as layout or logic
conf_profile

Profiles are linked to entities via the entitySpecId. Each profile can define different sets of forms for different use cases (e.g. create vs detail vs SLA edit).

Form Selectors

A form is identified by a unique selector string, such as:

  • tsm-ticket-detail
  • tsm-customer-new
  • tsm-order-sla-editor

These selectors are registered in configuration and used by the runtime engine to determine which form to load based on user actions or workflow state.

Widgets and Layout Components

Forms are composed of:

  • Widgets: UI elements that capture or display data (e.g. text field, date picker)
  • Layout Components: Containers that organize widgets (e.g. cards, tabs, sections)

Together, they form the visible structure of a form.

Metadata-Driven Behavior

Forms in tSM are not statically coded. Instead, they are defined entirely by metadata and interpreted dynamically at runtime. This means:

  • The same form can behave differently based on user, entity state, or configuration
  • Fields can be shown/hidden or become editable based on live data
  • Layouts and logic can evolve without changing any frontend code

Interaction with Backend

Forms are tightly integrated with backend logic via:

  • Processes: Workflows or automations triggered on form interaction
  • APIs: Used for loading LOVs, executing actions, or retrieving data
  • SpEL: Used for server-side validations and rule evaluations

At runtime, forms act as the user-facing interface for these backend systems — bridging UI and automation seamlessly.