A workflow is the ordered set of states the record of a job passes through, together with the moves between them. At Diotek a request raised on the website is held as a written record, including one that arrives while the phone line is busy. That is what a workflow gives a business: whoever reads the record sees where the job stands and who may push it forward.
What a workflow is: the states a record moves through
Take the plainest case, the one a business owner already describes without reaching for software vocabulary: a request comes in, it lands with somebody, it waits for an answer, it closes. Every stage in that line is a state, and every movement from one stage to the next is a move. Not one of those movements happens on its own, which is the part worth holding on to.
Name the parts and the word stops being vague. A flow is always the flow of some record: an order, a request, a booking, a work order. Attached to that record are the state it sits in right now, the move from one state to its neighbour, and the party entitled to make that move. Last comes the definition of the state in which the job counts as finished, and once all of it is assembled what you hold is readable on the record rather than framed on a wall.
A record does not walk from waiting to approved by itself; somebody or something performs every move, and the kinds of owner that exist get a section of their own further down. Whether anyone can see that move depends on where the state is kept. A state held in a field on the record travels with it, so whoever opens the job reads where it stands in the same glance. Keep it anywhere else and it stops travelling; the person who opens the record then sees the record but not where it stands.
The article on counting the programs a single job’s record has to cross stops at the edge of permission and approval and says so plainly. Behind that edge is the subject here: not how many programs a record touches, but which states it passes and whose hand moves it.
A diagram is a picture of the flow; the flow itself sits on the record
Some things never make it onto a drawing, and they happen to be the things a manager needs. A drawing does not say which state a particular record sits in, because the drawing looks identical for every record in the system. It does not say who is entitled to make a given move either; a role name written beside an arrow is a note, not a permission rule. Those facts have to be recorded somewhere in the software before anybody can act on them.
None of that makes the drawing worthless. A workflow diagram is a picture drawn to explain a flow, and explaining is real work: the first time a team talks a flow through, the chart gives everyone at the table the same vocabulary. What comes after what becomes visible there. The trouble starts when the explaining finishes and the record side has still not been built.
A drawing and a record live in separate places, and separate places drift apart. Update the chart on the wall and the state field on the screen does not notice. Add a new condition to the state list in the software and the chart on the wall goes quietly out of date. Where neither surface updates the other, the record is the one worth trusting, because the record is the one a customer is waiting behind.
Which is why asking to put a workflow into the system reduces, in practice, to questions of this shape: which states will exist, and who performs each move. The rest of this article is arranged around them.
Where a flow starts and where it ends
A flow opens when its record is created and closes in a state that record never leaves; both ends are conditions rather than dates, which is why the same flow runs at different speeds in different businesses and the calendar settles nothing. Deciding where that end falls is not a software job either: only the people doing the work know which condition a record will never move past, so software puts the question and waits for an answer. State lists built without asking carry a developer’s guess, and the guess has to be corrected in use.
None of that can be settled before the record itself is named, because a flow belongs to a record and not to the work. Air conditioning tracks a site survey or a service call; a pilates studio tracks a booking; lab-result interpretation tracks the wording that will reach the patient. Skip the unit and the state list has nothing to be a list of.
Leave the boundary undrawn and the list goes wrong in either direction. Reach too far and conditions appear for stages the record never passes through, so nobody keeps them current. Stop too early and the closing never gets written, leaving records parked in a final state forever. The overreaching list buries the useful states in noise; the short one builds a queue that never empties.
Flows also hand off to each other. A closed site survey leads to a quote, and an accepted quote opens a work order, so what you have is a set of linked lists and not a long one. Forcing them into a single list reproduces each failure above in the same place. Where the state field sits, and what a record attaches to and where the data boundary falls, is a data model decision taken elsewhere; this article only notes that they get decided together.
A state nobody wrote down is rebuilt every morning
Flows run perfectly well unwritten, and pretending otherwise would be dishonest; what keeps them running is a person rather than a piece of software. Whoever remembers the flow knows which request is sitting with whom, who signs off on what, and in what order things go. The information is complete, it is accurate, and it is held in exactly one place: that person’s memory. When they go on leave the flow goes with them, and what is left behind is a pile of records nobody can read.
So there is a test, and it can be run before any software is bought. Ask whether the answer to where this job stands can be read off the record, or whether somebody has to be asked for it. Read off the record, and the flow is written down. Asked of a colleague, and it lives in heads and gets rebuilt every morning from scratch. One record currently waiting in your own business settles it: if that record tells you where it stands your question lies elsewhere, and if it does not, a state field comes before another screen.
The air conditioning site where a request opens from the website and stays written down had this among its starting problems: a visitor who reached a busy phone line was simply lost. Now the same request opens from the site and is kept as a written record. The site itself is no longer a shop window standing outside the flow.
Written down carries a first condition of its own: the state belongs in a field on the record, because a state parked anywhere else does not travel with it. Whoever opens the job then has to go looking in a second place, which might be a spreadsheet, a message thread or a notebook. The state exists in every one of those and on the record in none of them.
Every move has an owner: a person, a role, an event or an outside party
Every move in a flow has an owner, which is simply the party entitled to make it. Leave the owner unwritten and the move starts to look automatic, when in truth somebody performs it on every pass. The kinds of owner differ, and the kind decides what the software is being asked for. Take the narrowest kind first, a named individual: at the platform where the reading that reaches the patient comes out of a doctor’s approval the wording is written and approved by the doctor in the panel. Where the approval step belongs in a flow was worked through on its own.
A role is the next kind up. At the platform where each party reaches the same timetable record only as far as its own permission goes a teacher, a parent and an institution manager each open that same timetable record, within what their permission allows. The advantage is durability: the individual holding the role can be replaced while the right stays where it was put. How looking at the same record according to your role is built was covered on its own, and the role matters here only as the owner of a move.
The remaining kinds sit further from the desk. An event owns a move when no decision by a person carries it, only a condition the rule already defines, such as a waiting period running out. Pilatesco posts a no-show to the package balance in the way the rule defines, and the rule is what decides whether the entitlement comes back. An outside party owns a move when the business is not involved in it at all: at Diotek a visitor raises the site survey or the service request unaided. Because an outside party can only make moves that need no permission, the condition a public move ends in has to be fixed in advance, and the record arrives ready for someone inside to pick up.
The rows below are sorted by the kind of owner rather than by project: each row carries what starts the move, what the move leaves on the record, and where it is built that way.
| Owner of the move | What starts the move | What the record keeps | Where it is built that way |
|---|---|---|---|
| A person with a named permission | The authorised party reads and approves | The final wording and the doctor who approved it | Tahlil.com, the reading written in the doctor’s panel |
| A role: the person changes, the right stays | Access bound to the role’s permission | One shared record, opened by each role within its permission | Vipkurum, where each role opens that timetable record at its own level |
| An event: no decision by a person carries it | A condition defined in the rule coming about | A balance movement shaped by the rule | Pilatesco, a no-show posting to the package balance |
| A party outside the business | A visitor opening the request unaided | A written request, independent of a free phone line | Diotek, site survey and service request |
What each row really shows is that the owner determines the work: a person owner means recording the approval, a role owner means attaching the right to the role, an event owner means writing the rule, an outside owner means fixing a stopping condition. And there is no move anywhere without an owner, only a great many moves whose owner nobody wrote down. Where that is the case, circumstance decides the entitled party on each pass: whoever is free, whoever remembers, whoever is at the screen when it comes up. An unwritten owner is not an absence. It is a rule that changes with whoever fills it.
A move can change something beyond the record itself
Some moves do more than advance a state: they also shift a second record. A state list cannot show that on its own, because the list holds where a record stands, while the second effect is about what some other record has become.
At the booking system where a reservation draws a class off the package balance that effect lives in the rule: as a reservation is written into the calendar, a class comes off the customer’s package, and that balance is kept on the customer’s own record. How a reservation moves that balance was opened in the article on request types built as separate flows. What matters here is only where the second effect is defined.
A move whose second effect was never written gets caught in the most expensive place a flow has. The state looks as though it advanced while the entitlement or the balance behind it did not. The catch also comes late: the discrepancy surfaces when somebody asks about the balance, not when somebody looks at the record. At that point which move should produce which movement gets discussed again, and the outcome of the discussion is written into that day’s decision rather than into the rule.
So writing a flow down means writing a second question beside every move: what does this move change apart from the state. Asking it per move produces a document that looks nothing like a diagram. What comes out is rules rather than arrows.
Not every move earns that question. Where a move does nothing but advance a state, putting a rule behind it buys nothing. What has to be attached to the flow is not the state itself but the second record that changes with it, and where no such record exists a state field is enough on its own.
A finely drawn state list names the work that is waiting
The number of steps on a state list is a visibility decision, and the decision cuts in either direction. With nothing between open and closed, an open record cannot tell you who is holding it, so that answer goes back to being passed around in conversation. Make the list finer, though, and you take on the updating: a state nobody maintains returns a wrong answer, which is worse than no answer, because somebody reads the screen, concludes the job has moved, and the record has not moved at all.
That gives the test for admitting a state: it has to name a condition that genuinely sits in somebody’s hands. In progress names nobody and therefore says nothing about where the work is waiting. Waiting for the doctor’s approval names somebody, and so does waiting for the customer’s reply. Run that question down every row of your list: in this condition, whose hands is the record in? At Tahlil.com a reading still in the pre-read state is waiting for the doctor.
Naming waiting states this way pays off in the work it implies. A record waiting on an outside party needs a reminder. A record waiting on a role needs permissions distributed, and when the holder of a role is away, somebody else carrying that role can take over. A record waiting on an event needs the length of the wait watched.
Fineness has a ceiling, though. Once keeping the list current costs more than the work it tracks, the list goes stale and people stop opening it, and the state on the screen stops describing reality. What it describes then is what the last person to touch it happened to remember.
Where a flow does not need software, and where our evidence stops
Not every business gains from putting a flow into software. Where the same person makes every move and the job closes in the same sitting, a state field costs more than it saves: nothing is handed over, nobody is left waiting, and whoever opens the record is whoever closes it. Volume is not what settles this. A workshop turning over plenty of jobs, each run by the same person throughout, leaves the state field empty, while a small outfit whose every job waits on an approval has the list earning its keep from the start. A flow begins where work passes from one person to the next.
Here is where our evidence stops. The flows we can show are the flows of operational records: a request, a booking, a work order, an entry log, an approval. We have nothing to show on corporate approval chains, and nothing on budget flows. That is not a negotiating position, it is the edge of what we can put in front of you.
Writing that down narrows nothing, it just tells you whether you are at the right address: if what you are shopping for is a layered approval chain in itself, what is described here will not cover it, and a first conversation is a cheaper place to find that out. Which leaves the one thing worth doing. If the record itself cannot tell you where a job is waiting, a drawing is the wrong place to begin; begin with the list of states and the owner of each move, which is where the work starts on the side that tracks a job’s state and who moves it.
