Before you improve a workflow, name what exists in it.
Most workflow redesigns start too late. Teams jump to tooling, automation, dashboards, or meeting cadence before they agree on the objects the workflow is supposed to manage. Then the tool inherits the confusion. A project field becomes a task field. A request becomes a commitment. A blocker becomes a complaint. An approval becomes a vibe check from someone senior.
The basic objects of work are simple, but they need clean edges.
A request is a demand for attention. It may come from a customer, executive, teammate, system alert, regulator, partner, or internal process. A request is not automatically a commitment. The first question is intake: should this enter the system, be rejected, be deferred, or be routed somewhere else?
A task is a unit of work with an intended output. It needs a next action, an owner, and a done condition. If a task cannot answer those three questions, it is probably a note, a wish, or a project hiding in a smaller costume.
A project is coordinated work across multiple tasks, people, dependencies, or phases. Projects fail when they are managed like large tasks. The workflow needs a way to represent milestones, risks, decisions, handoffs, and scope changes, not only checkboxes.
An owner is the person accountable for moving the work to its next meaningful state. That does not mean they do every piece of the work. It means they are responsible for clarity, progress, escalation, and closure.
A state is the actual condition of the work. Not the color. Not the label somebody selected because the tool required it. The condition. Is it waiting for triage, ready to start, actively being worked, waiting on a dependency, blocked by a decision, under review, approved, rejected, shipped, reopened, or done?
A blocker is something that prevents progress and requires intervention. A dependency is something the work needs from another object, team, system, or decision before it can proceed. An exception is a case that does not fit the normal path and needs a named handling rule.
These are different things. Treating them as one bucket called "blocked" destroys signal.
An approval is a decision gate. It should say who decides, what they are deciding, what evidence they need, and what happens if they approve, reject, or do not respond.
A handoff is a transfer of responsibility. It is not a Slack message. It requires enough context for the receiver to accept the work and enough clarity that the sender is no longer pretending to own it.
An SLA is a promise about time, priority, or response. It only matters if the workflow can identify when the clock starts, when it pauses, what counts as breach, and who sees the breach before the customer does.
Done is the most abused object in work. Done should mean accepted, recorded, and no longer requiring normal workflow attention. "I did my part" is not done. "I sent it over" is not done. "Waiting to see if anyone complains" is not done.
The point of naming these objects is not to make the workflow fancier. It is to reduce arguments later. When a team knows the difference between request, task, project, blocker, dependency, approval, handoff, SLA, and done, it can design simpler rules.
Without those rules, every workflow becomes a negotiation. People spend their energy interpreting the system instead of using it.
This is part 2 of 10 in Workflow Ontology.
