Quick answer
A useful state does more than answer “where is this work?” It also makes clear who owns the next move, what must be true to move on, what information is needed, and where an exception goes. Treat each state as an operating commitment with five parts: purpose, accountable role, transition condition, required information, and exception route.
The problem is not the number of states
Many systems begin with a few simple labels and gradually collect “waiting for reply,” “needs review,” “urgent,” and “other.” Those labels can help a conversation, but they do not create accountability on their own. If no one knows who acts next or what ends the state, the team still has to ask in chat.
The goal is not to force every activity into a rigid flow. It is to clarify the moments when a request changes hands, waits for a decision, or needs to leave the normal path. This is an original OXMODE operating-design framework, not an audit standard or legal advice.
The five questions for every state
1. What does this state make clear?
Write one sentence about the outcome, not a technical action. “Waiting for an authorized decision” is clearer than “Pending.” “Input is being completed” is clearer than “Needs action.” A purpose statement also exposes states that merely repeat a person’s name or a tool label.
2. Which role is accountable while work is here?
Every state needs a role accountable for the next move. That role does not have to perform every task, but it must be the clear place to receive, coordinate, or route an exception. Use roles rather than individual names so the flow remains usable when people change.
3. What condition permits the transition?
A transition condition turns a state into a rule that can be checked. The required details may be complete; an authorized role may have agreed; or a check may have returned a result. NocoBase documents that an approval workflow can begin before or after data is saved, depending on the business meaning of the approval step.[1] It is a useful illustration: the timing of a transition should reflect what the team intends to control, not merely what is convenient to configure.
4. What information must be visible at this point?
The person receiving work should not need to search several screens or ask the requester for information the system already holds. List the minimum information for the next action or decision: request context, the relevant source, a due date where applicable, and the reason for a previous decision. Do not expose sensitive data merely because it may be useful; show only what that role needs.
5. Where does an exception go?
An exception is not a workflow failure. It is a situation that does not satisfy the ordinary condition: missing information, conflicting data, an out-of-scope request, or a different decision. For each state, choose a clear route: return for completion, escalate to an authorized role, or close with a reason. When exceptions always move to private messages, the team loses evidence needed to improve the process.
A short design table before configuration
Use this table in a conversation between the process owner and implementer:
| State | Purpose | Accountable role | Transition condition | Exception |
|---|---|---|---|---|
| Intake | Confirm that the request has the needed input | Coordinator | Required fields complete | Return for completion |
| Review | Make a decision against defined criteria | Authorized role | Decision and reason recorded | Escalate appropriately |
| Delivery | Complete the approved action | Delivery role | Completion evidence available | Report a blocker |
| Close | Record a result that can be found later | Process owner | Result recorded | Reopen by rule |
This is a design prompt, not a mandatory flow. A small process may need only two states; a cross-functional one may need more control points. What matters is that every state can answer the five questions.
Do not use a state to hide an unclear decision
When a team repeatedly adds labels to handle the same situations, pause and ask: which decision has no owner, which criterion is missing, or which input is insufficient? NIST’s AI RMF describes governance as a cross-cutting function that supports activities to identify, measure, and manage risk, and says those activities should fit the organization’s context.[2] A practical workflow translation is simple: do not copy a state template; clarify the accountability and risk of the flow you are designing.
Checklist before a new state goes live
- The state name describes an outcome or decision, not only a generic label.
- One role is clearly accountable for the next move.
- The transition condition can be explained and checked.
- The next role sees the information it needs, without unnecessary sensitive data.
- There is an exception route and a recorded reason.
- The team has tried one normal request and one exception before use.
OXMODE consults on and builds AI-First operating systems, from data and permission design to controlled workflows. If your team needs to turn a recurring process into a flow with clear accountability, contact OXMODE to define an appropriate scope.
Frequently asked questions
Should there be one state for each person in the process?
Not by default. A state should describe the condition of the work or the decision required; ownership is an assignment property. Create a separate state only when the step has a distinct purpose, transition condition, or evidence that needs review.
When should a state require approval?
Use approval when moving forward creates a decision for which an authorized person should be accountable, or when the data and impact need review before work continues. Design the approval view so the reviewer can see the relevant information, proposed action, and reason.
Must every transition condition be automated?
No. Some conditions are well suited to automated checks, while decisions needing contextual judgment should remain with an authorized person. Start with simple, explainable conditions; automate further only when data, authority, and exception handling are clear.
