How to model product data around real workflow states

Identify objects by their role in the workflow

Start with the nouns users rely on, then check whether they represent distinct objects. In a workshop booking product, a workshop, a scheduled session, a participant, and a registration may each have their own identity. Combining them into one screen-shaped record can make changes difficult to interpret. A participant’s name can change without creating a different registration; a workshop can have several sessions without becoming several unrelated products. Write what each object represents, who controls it, and which other objects it depends on. This explanation helps the team see meaning before choosing storage details.

Describe states and allowed transitions

List the states that matter to behavior: a registration could be draft, confirmed, cancelled, or awaiting a decision. Define the conditions and authority required to move between them. Consider what happens when a session changes after confirmation and whether cancellation can be reversed. Avoid a collection of unrelated boolean flags that permits impossible combinations. Use a state table or examples to reveal contradictions. The purpose is not to make the model elaborate; it is to ensure the system can explain why a record is in its current state and which actions are valid next.

Decide what history and removal mean

Ask which changes need to remain understandable later. A registration’s current state may be cancelled, but staff may need to know whether it was previously confirmed when interpreting attendance. Decide what to retain, for how long the product requires it, and who can access it, without collecting unrelated information. Define deletion in product terms: removing a draft may differ from removing a session with registrations. Consider linked records and user expectations. If a display name changes, historical notes should not silently become misleading. These decisions belong in the model and workflow, not in scattered cleanup code.

Walk the model through difficult examples

Use a small set of scenarios: duplicate names, a participant switching sessions, a cancelled workshop, a transferred organizer role, and a partially completed registration. Show how identity, relationships, and state behave in each case. Review the examples with product and engineering together. The checklist is to define objects, separate identity from labels, map ownership, specify transitions, choose necessary history, and test removal. Document unresolved cases explicitly. A useful data model makes the product’s rules easier to express and verify; it should not require the team to remember unwritten exceptions every time a record changes.

Write an example showing the same object before and after a change. If a participant switches sessions, specify which identity remains, which relationship changes, and what history is necessary to explain the move. Ask whether reports and access rules interpret the new state consistently. This simple before-and-after review can reveal a mistaken model before the team has built several screens around it.

Use the agreed objects and transitions to define API actions, response meanings, errors, and retry behavior so callers do not invent a different interpretation of the data.How to define API contracts before integrating product features