When an order, request, or case moves through several applications, it is common for each team to see a different version of its situation. The CRM may show it as “closed,” the operations tool as “pending,” and customer service as “on hold.” This is not always a technical failure: it is often the result of not defining what each state represents, which system has the authority to change it, and which facts support it.
Process state design in integrations turns a business journey into an understandable contract between product, operations, and technology. Its purpose is not to impose an identical catalog on every application. It is to ensure that a shared state has an unambiguous meaning, observable evidence, and transition rules that all connected systems respect.
Diagnosing Whether You Need a Shared State
Not every system needs to use the same internal states. An application may require technical steps that provide no value to other teams: format validation, a work queue, synchronization, or calculation. The problem arises when a state is used to coordinate decisions across different domains or to communicate a promise to the customer.
It is worth establishing a shared model if one or more of these signals occur:
- Two teams answer the question “What happened to this request?” differently.
- One application enables an action based on a state that another has not yet recognized.
- Cancellations, rejections, or resumptions are handled through manual channels.
- Reports aggregate local labels that appear equivalent but include different cases.
- Integration retries return a process to an earlier stage or duplicate tasks.
If the only need is to display local information, a translation table may be enough. For example, several technical states can be presented as “in progress” in a business view. But if multiple systems make decisions, bill, send notifications, or close work according to that stage, an explicit contract is required. Translating labels does not replace defining ownership or transitions.
Designing the Model from the Business Journey
The best starting point is not the list of states in an existing tool, but the lifecycle experienced by the business entity. Map the complete journey of an order, case, or request, and ask what commitment each stage represents. Many cross-functional processes include five moments, although their names may vary:
- Initiation: the entity exists and has been received or created.
- Assessment or commitment: information is validated and the request is accepted, rejected, or sent back for correction.
- Execution: work is actively being performed to fulfill the commitment.
- Outcome: execution ends in success, failure, rejection, or cancellation.
- Closure: subsequent effects are completed, such as communication, reconciliation, or archiving.
These moments do not require creating five states. They help uncover relevant decisions. A state deserves to exist when it changes what a person or system can do, what expectation another party should receive, or what operational control is required. If two states lead to exactly the same decisions, they probably add complexity without value.
For each shared state, document at least:
- Its definition in business language and the observable condition that proves it.
- The entity to which it applies and, where relevant, its scope: full request, line item, shipment, or task.
- The owning system that can confirm it.
- Allowed source states and valid triggers.
- Actions enabled, prohibited, or required upon entering it.
- The exit policy: automatic, manual, triggered by an external event, or time-based.
A definition such as “completed when the team finishes” is ambiguous. A better definition is: “completed when the operations system records that all mandatory tasks for the request have finished successfully.” This can be verified, audited, and automated.
Do Not Mix State, Event, Reason, and Action
Much inconsistency comes from using one label for different concepts. Separating them reduces discussions and preserves context without multiplying states.
- State: the entity’s current persistent condition, such as “in execution” or “cancelled.”
- Event: a fact that occurred at a point in time, such as “payment authorized,” “documentation received,” or “operation started.”
- Reason: a coded explanation for a decision or outcome, such as a rejection or cancellation reason.
- Action: an instruction intended to cause a change, such as “cancel request,” “retry shipment,” or “assign agent.”
For example, “customer called” should not be a state: it is an interaction event. “Cancelled as a duplicate” combines a final state and a reason. Separating them makes it possible to measure cancellations without losing the cause and avoids creating an endless list of variants.
You must also distinguish between business state and technical state. “Message pending publication” may be essential for observability, but it should not replace “request accepted.” Keep the business state stable despite transport details; expose technical data when it helps resolve incidents.
Assigning Authority and Controlling Transitions
A shared state needs one source of truth for each decision, even when the entity is replicated in several places. The CRM may own request intake; the operations system may own execution; and a financial system may own payment confirmation. The risk is allowing multiple systems to write the same state without a precedence rule.
Build a simple matrix containing the state, authorized system, evidence, and consumers. Then define allowed transitions. A diagram is useful, but the rules must be implementable. For example:
received -> validated -> in_execution -> completed received|validated|in_execution -> cancelled validated -> rejected
Not every transition should be reversible. Terminal states should be treated as terminal unless there is a governed correction. If an error appears after marking a request as “completed,” it is not advisable to silently return it to “in execution.” Record a corrective action, the reason, the responsible party, and, if the business requires it, a new cycle or a derived entity.
Intermediate states are necessary when they change an expectation or an operational rule. “Waiting for customer” may justify pausing a deadline and triggering a communication; “queued” may be an internal condition that should not leave the operations system. Also define time limits: how long a request may remain in each phase, who reviews the exception, and which alert is generated.
Cancelling, Retrying, and Recovering Without Creating Regressions
Distributed integrations fail, are delayed, and may deliver the same message more than once. State design must account for this. Publishing a change does not mean that every consumer processes it once only or in perfect order.
For every state change, publish a stable entity identifier, a unique event identifier, the new state, the effective date, the source, and a version or sequence. A consumer must be able to safely ignore an event already applied and identify an old one. The update operation must be idempotent: processing the same change twice cannot create two tasks, two notifications, or two cancellations.
Technical retries should not change the business state by themselves either. If a message announcing “in execution” fails to be delivered, retry delivery and record the incident; do not return the request to “validated.” When messages arrive out of order, choose an explicit policy: reject events with a lower version, retain them for review, or accept them only if the transition remains valid.
Cancellation requires a clear business decision. Determine:
- Which states allow cancellation by the customer, operations, or automatically.
- Which effects must be compensated: tasks, reservations, communications, or subsequent transactions.
- When cancellation is immediate and when it remains “requested” until a system confirms that work can be stopped.
- Which reasons are mandatory and which roles can perform a manual correction.
A manual change must leave an audit trail; it is not an invisible exception. Record who made it, when, why, the previous state, and which effects were notified. This information helps resolve complaints and improve flawed rules.
Example and Controls Before Deployment
Imagine a request that starts in a form, is managed in a CRM, is fulfilled in an operations application, and is viewed by customer service. The form can create “received,” the CRM can confirm “validated” or “rejected,” and operations can declare “in execution” and “completed.” Customer service consumes the shared state but does not modify it. If the customer requests cancellation during execution, customer service creates a cancellation action; the operations system later confirms “cancelled” or reports that it is no longer possible to stop it. This prevents a request from being confused with an outcome.
Before implementation, review this checklist:
- Does every state correspond to a real business or operational decision?
- Is there an observable condition and a single authorized system to confirm it?
- Are reasons, events, and actions separated from the persistent state?
- Have invalid transitions, terminal states, and exceptional corrections been defined?
- Can consumers handle duplicates, delays, and out-of-order messages?
- Are there alerts for abnormal time spent in a state and reconciliation between the source and replicas?
- Do contract changes include a version, owners, and a compatibility plan?
The model should evolve with the process, but not through informal label changes. Periodically review the states with the most waiting time, manual interventions, discrepancies, or support queries. These signals indicate that a definition is insufficient, an event is missing, or a technical state is being used to represent a business decision. A small, explicit, governed contract is more useful than an exhaustive catalog that no system interprets in the same way.