A state model steers the lifecycle of a Businessobjekt: states, allowed transitions, rights per state, required fields per state, and rules on transition. Quote becomes order. Order is delivered. Delivery is invoiced. Without a state model, status stays free text and control stays chance. With a state model the flow becomes steerable, auditable, and automatable. For decision-makers: that is process automation in ERP, not only a status column.

What states and transitions deliver

States name where the case stands. Transitions name who may move where. That separates business truth from operator error. An order does not jump from “captured” to “paid” if the transition is not defined. Rights per state keep roles clean: sales may create, logistics may deliver, finance may approve.

Required fields per state prevent critical data from missing before the next step is possible. Rules on transition cover logic that mask and state alone do not deliver. When that is not enough, the rules engine applies. Platform context: Nuclos 5 as a platform.

State model and work on the mask

State affects operation: editable fields, visible actions, handling of subforms. That keeps the process steerable in the same work view. Low-code here means: lifecycle as configuration, not as an undocumented code path. The model lives in the Nuclet.

For executives, plannability counts: scope of a process is also scope of its states. For IT, governance counts: transitions are releasable, auditable, and testable.

Nuclosian and state models

Nuclosian sets state models and shows the diagram in chat. You describe the flow in business language. Nuclosian writes states and transitions directly into the instance. There is no diff for that. That does not replace alignment between business and IT. It makes the agreed flow faster to configure. Entry points: Nuclosian: first steps.

Technical wiki: Statusmodell. Configuration reference there. Here the lexicon answer: the state model is the governed lifecycle of your case.

What a state model is not

A state model is not a chatbot and not a substitute for process clarification. Unclear approvals do not get better through more states. Equally wrong: too many micro-states that nobody steers. Few clear states with hard transitions beat fine taxonomies without discipline. Anyone who only wants to report does not need a state model. Anyone who wants to approve and automate cases does.