A workflow is a definition, not a description
Most teams have processes documented somewhere — a wiki page, an onboarding deck, a shared document. These describe the process without enforcing it, which means adherence depends on memory.
A workflow defined in the system where the work happens is different in kind. The steps exist as records, ownership is assigned, and progress is observable without asking.
What belongs in a workflow definition
Four things, at minimum, or the definition is not actionable.
- Steps, in order, each with a clear completion condition.
- An owner per step — a person or a role, never implied.
- A trigger that starts the process, so it does not depend on someone remembering.
- An end state, so it is clear when the process is finished rather than abandoned.
Model the process you have
The common failure is modelling an idealized process that nobody currently follows, then wondering why the workflow is bypassed.
Encoding the real process — including the awkward approval nobody likes — gives you something that is used, and therefore something you can improve from. An aspirational workflow is just a second description.
Workflows and pipelines are different tools
A pipeline tracks the state of a deal moving towards a decision. A workflow runs a procedure with steps that must each be completed.
Sales progression suits a pipeline; onboarding a new client suits a workflow. Using one for the other produces either a pipeline with twenty stages or a workflow that cannot represent a deal going backwards.