The Business Object Is the Center of the Workflow
Why workflows and data models must be designed together if a business process is going to become executable.
Every real workflow has a protagonist. A loan, a claim, a patient, a contract, a deal, an order. The workflow exists to move that thing through a set of states. If the thing is fuzzy, the workflow is fuzzy.
This is the part teams skip. They design the workflow as a sequence of steps and discover, halfway through, that the steps are operating on different objects. One step is reading from the order. The next is reading from a related quote. The next is writing to an invoice. There is no single, shared definition of “the thing we are working on.” Without it, every join becomes a guess and every status becomes a lie.
The object holds the workflow
The business object is the center of the workflow. The object holds the state. The object accumulates the history. The object is what the workflow is actually about. Every step either reads from it, writes to it, or makes a decision about it.
A workflow is therefore not a pipeline. It is a lifecycle of an object. The right question is not “what are the steps” but “what are the states this object can be in, and what events move it between them.”
What gets easier
The data model has a center of gravity. Schemas hang off the object, not off the screen that happened to be designed first. Migrations and integrations have a coherent point of reference.
Most permission questions turn out to be about the object, not the action: can this user see this claim, can this user approve this loan. Once the object is explicit, the system can express that directly instead of encoding it in scattered checks.
Reporting stops requiring translation too. “How many deals are stuck in legal review” becomes a query over the object’s state, not a derived measure from a join across five tables.
Hand-offs get cleaner. When an object moves from sales to delivery, the delivery team is not inheriting a sales record. They are picking up the same object at a new lifecycle stage, with the full history attached.
How I keep the discipline
Name the object early. Define its state machine before the screens. Refuse to let the workflow operate on anything that has not been promoted to an explicit field on the object. Side data hidden in payloads or notes is technical debt with a long fuse.
There is a temptation to model the object in too much detail at the start. Resist it. Start with the smallest object that is recognizable to the business. Five fields and four states is plenty if the five and the four are the right ones. Add to the model when the workflow needs it, not when the imagination does.
The workflow and the object are the same artifact viewed from two angles. The workflow says how the object moves. The object says what is moving. Designing one without the other produces software that almost works.