Replacing the "Status" Column: Designing Real Workflows with States and Transitions

Open almost any operational spreadsheet and you will find a column called Status. In it: “In progress”, “in prog”, “WIP”, “Done”, “done?”, “Waiting on Mark”, and one cell that just says “see email”. Some rows are green, some are yellow, and one is a shade of orange nobody can explain.

That column is trying to describe a workflow. It just has no rules. Moving to proper tooling is your chance to give it some.

What a status column is really doing

A status column records where each item is in a process. A customer request, an order, a hiring candidate: each one moves through stages from start to finish.

In a spreadsheet, anyone can type anything into that cell at any time. There is nothing stopping an order jumping from “New” straight to “Shipped”, skipping payment. Nothing records who changed it or when. And because the values are free text, filtering for “everything in progress” means guessing every spelling.

The fix is to treat the workflow as what engineers call a state machine. Despite the name, it is a simple idea: a fixed list of states an item can be in, and a fixed list of moves, called transitions, between them.

Step one: define the states

Start by listing every stage an item genuinely goes through. Not every label people have typed; every real stage.

Take a fictional customer onboarding team. Their sheet has 14 distinct values in the Status column. When they sit down and talk it through, those collapse into six real states:

1. Signed – contract received, nothing started.
2. Kickoff scheduled – first meeting booked.
3. Configuring – setup work under way.
4. Awaiting customer – blocked on something from the client.
5. Live – customer is using the product.
6. Cancelled – onboarding stopped.

“Waiting on Mark” turned out not to be a state at all. It was an owner, and belongs in its own field. “See email” was a note. Separating these out is half the value of the exercise.

A good test for each state: could someone new tell, without asking, whether an item belongs in it? If not, the definition needs work. Write a one-line definition for each state and put it somewhere people will see it.

Step two: define the transitions

Now list which moves between states are allowed. This is where a real workflow differs from a dropdown menu.

For the onboarding team, it might look like this:

Notice what is not allowed. You cannot go from Signed straight to Live. You cannot move something back from Live to Configuring without a deliberate decision. That gap is a feature: if it needs to happen, it should be rare enough that someone thinks about it.

Keep the list short. If you find yourself with 30 transitions, you probably have too many states, or you are trying to model exceptions that should just be handled by a person with the right permissions.

Step three: attach rules to the transitions

Transitions are where you put the guardrails that a status column never had. Common ones:

• Required fields. You cannot move to Kickoff scheduled without a kickoff date. You cannot mark something Cancelled without a reason.
• Permissions. Only certain roles can make certain moves, as in the table above. “Permissions That Make Sense: Who Should See and Edit What” covers how to design those roles.
• Automatic actions. Moving to Awaiting customer sends the client a reminder; moving to Live notifies the account manager.
• Timestamps. Record when each item entered each state. This is what lets you answer “how long does configuring usually take?” later.

Most no-code database platforms and internal app builders support some version of this, often as a single-select field combined with validation rules and automations. Even if your tool cannot enforce every rule, writing them down still helps people follow them.

Be careful with automations. One useful notification per transition is helpful. Five is noise. “Automations That Actually Save Time (And the Ones That Just Create Noise)” has more on drawing that line.

Step four: handle the messy middle

Real processes have exceptions. A few patterns help without blowing up the design:

• A “blocked” or “on hold” state for things waiting on outside events. Pair it with a required reason field so it does not become a graveyard.
• An admin override for the rare case where something genuinely needs to move backwards. Limit it to one or two people and log it.
• Separate fields for separate questions. Priority, owner and health (“at risk”, “on track”) are not states. Keep them in their own fields so the state stays clean.

The onboarding team’s old sheet used yellow highlighting to mean “at risk”. In the new tool, that became a separate health field, which meant they could finally filter for at-risk accounts across every state.

What you get for the effort

Once states and transitions are defined, several things become easy that were painful before. Filtering is reliable because there are only six possible values. Reports can show how many items sit in each state and how long they stay there. New team members learn the process from the tool itself. And when something goes wrong, the history shows exactly who moved what, and when.

None of that comes from a better spreadsheet column. It comes from deciding, explicitly, how the work is supposed to flow.

Where to start this week

• Export every distinct value in your current status column and count how many there are.
• Group them into real states with your team, and write a one-line definition for each.
• Draw the allowed transitions as a simple table, including who can make each move.
• Pick two rules to enforce first, such as a required field on one transition and a timestamp on every state change.