State Models

What is a state model

A state model is a special field type (State Model, see Field Types) that describes a record's lifecycle: the set of possible statuses and the allowed transitions between them. Unlike a regular value-list field, the status can't be changed to just anything — only to statuses that the current status allows a transition to.

An entity can have only one State Model field.

For a complete, step-by-step example of how a state model works in practice — ticket statuses, who changes them, what happens on each transition — see Service Desk (IT Support): it walks through the full mechanics using a concrete status chain, "New → Assigned → In Progress → … → Closed."

Statuses

Each state model status is defined by three attributes:

• name — a multilingual label visible to users;
• value — the technical value actually stored in the record's data;
• color — used to visually highlight the status in lists, the record card, and the timeline.

A status has no separate "initial" or "final" flags — these are derived from the transitions:

• a status is considered initial if a transition leads to it with no source specified (i.e., it's assigned to the record on creation);
• a status is considered final (terminal) if it has no configured outgoing transitions — the record card and timeline mark such a status with a "final" icon.

Transitions

A transition is a directed link "from status A to status B." Transitions are configured in the entity editor, on the State Model field's configuration: for each status, the administrator specifies which other statuses it can move to.

A transition isn't tied to a specific role or user — anyone with permission to edit the record (and see this field) can perform any of the allowed transitions. Restricting which specific people or roles are allowed to move a record between statuses isn't handled by the state model itself, but by the corresponding business logic — for example, by assigning a task to a specific role in a business process, which then changes the status once the task is completed.

How it looks on the record card

The status field on the record card is a dropdown, but it doesn't show every existing status — only the ones the current status is allowed to transition to. For example, if "In Progress" only has transitions configured to "Pending" and "Resolved," the user will see exactly those two options (and nothing else) in the dropdown.

If a status has no outgoing transitions configured (it's terminal, but this might be a configuration mistake rather than an intentional final state), the status list shows all available options as a safety net, and a warning appears under the field saying that no transitions are configured from the current status — this prevents a record from getting "stuck" in a status with no way out.

Status timeline

If an entity has a State Model field configured, the record card shows a status tab with a visual timeline: a graph where nodes are statuses and arrows are the configured transitions. On the graph:

• the record's current status is highlighted;
• statuses already passed through are marked as visited;
• statuses the record hasn't reached yet are shown faded and dashed;
• terminal statuses are marked with a separate icon.

Clicking any visited or current status opens the record's change history for the time it spent in that status. The timeline is a tool for viewing a specific record's history, not a place to configure transitions (transition configuration is a separate screen in the entity editor).

One set of statuses, multiple record subtypes

If an entity has record subtypes (a Type Extender field, see Field Types), statuses aren't duplicated for each subtype. All statuses (names, colors, values) are stored once in the entity's shared registry. For each subtype, the administrator only configures separately:

• which of the shared statuses are available to that subtype (via checkboxes);
• which transitions between those statuses apply specifically to that subtype.

In practice, this means: if you need to rename a status or change its color, you do it once and it immediately applies to every subtype that uses that status. And to give different subtypes different lifecycles (for example, "Incident" having one set of transitions and "Change Request" another), you only need to configure the transitions for each subtype, without recreating the statuses themselves.