How to Set Up a Custom Kanban Status Workflow in Taskora

Most kanban boards start with three columns, To Do, In Progress, and Done, plus a hope that the work sorts itself out. Two weeks later the board lies. Cards sit in In Progress that are really waiting on a client review, and finished pieces linger short of Done because two people mean different things by it.

A custom kanban status workflow fixes that. You name the statuses your process actually has, mark where work starts and where it ends, and draw the moves a card is allowed to take. The board then matches how your team works, instead of how a template guesses. This guide walks through setting one up in Taskora, with an editorial pipeline as the worked example. You can copy the same structure for the next process your team runs.

What a custom kanban status workflow is

In Taskora, streams are projects, and every stream gets its own kanban board. Each stream also carries its own custom status workflow. A workflow is the set of statuses a card moves through, with one start status where new cards land, one final status where they end, and the allowed transitions between them.

Transitions are what make the workflow real. If a piece should never jump from Idea to Published, it can't, because that move was never drawn.

We made the workflow belong to the stream because growing teams rarely run only one kind of work. Editorial, client delivery, and ops each move at their own pace, and the teams page shows how that split looks in one workspace.

The example: an editorial pipeline

Here's the process this guide models. A content team publishes articles for clients, and its work moves through five statuses:

Idea
Drafting
Editing
Scheduled
Published

Each status names a state the team already says out loud. Nobody needs training to understand Drafting, and that's the test every status in your own workflow should pass.

The moves follow the handoffs, and Step 4 lists them in full. What matters here is what's missing. There's no move from Idea straight to Published, and no move from Drafting straight to Scheduled. Unedited work doesn't ship, because the board won't carry it there.

The same shape works for client work too. Request, Scoping, In Progress, Client Review, Delivered. The statuses change. The rules, one start, one final, allowed transitions in between, stay the same.

Step 1: Create a stream for the process

Create a stream and name it after the process, like Editorial or Client Delivery. The stream's kanban board is where the workflow will live, and because streams are separate, this process gets its own board instead of a corner of somebody else's.

Keep one process per stream. If the team later runs a second process with different stages, it gets a second stream and a second workflow. Mixing two processes onto one board is how you end up with vague columns nobody trusts, like a second Waiting.

Step 2: Add the statuses

In the stream's workflow settings, add each status under the name your team already uses in conversation. Use Editing rather than Peer Review Stage 2. If a status needs a sentence of explanation every time it comes up in standup, rename it before anyone has to learn it.

Start with four to six statuses. A board with fifteen columns stops getting updated, because updating it becomes a chore in itself. Adding a status later is a small edit.

Step 3: Mark the start status and the final status

Every workflow has exactly one start status and one final status. The start status is where new cards land when they're created, so it should be the easiest column to drop a card into. For the editorial team, that's Idea. A thought that's quick to jot down is a thought that doesn't get lost.

The final status is the one that means done, with nothing left owed. For the editorial team, that's Published. Cards in the final status are your team's finished output. Pick a final status that requires nothing after it. If Published still needs a social push, that push belongs in a status before it.

Step 4: Draw the allowed transitions

Transitions are the rules of the road. Draw each move a card is allowed to make, and leave the rest off the list. For the editorial workflow:

Idea to Drafting, when a writer picks the piece up
Drafting to Editing, when the draft is ready for review
Editing to Drafting, when review sends it back with notes
Editing to Scheduled, once the piece is approved
Scheduled to Published, when it goes live

The rework loop is the transition teams forget, and it's the one that keeps review honest. Without Editing to Drafting, reviewers either wave work through or park their notes in comments while the card sits in limbo. Draw the loop on purpose.

Leave the shortcuts off too. If Idea could jump straight to Published, someone on deadline would use that door, and the board would stop meaning anything. The allowed transitions are your team's rules for what has to happen before work ships, written down on the board itself.

Step 5: Run the board for a week, then adjust

Once the workflow is saved, the board columns follow it. Drag a card across an allowed transition and it moves. A Drafting card can't jump straight to Published, because that move is off the list.

Give it a week of real cards before you change anything. Then make the changes the week pointed to. A status nobody uses is a state the team doesn't think in, so merge it into a neighbor. A column that's always full while the next one sits empty means a state is missing in between, so add it. Workflows get good through small edits.

Where this fits in the rest of Taskora

The workflow shapes how work moves. Sprints shape how work is planned. A sprint is a batch of time-boxed work with a name and an end date. Sprints are Taskora's custom cycles. With custom cycles you set the length, from a week to a month, and name each one what your team already calls it. When a sprint closes, anything unfinished rolls into the backlog, ready for the next sprint on its own.

Documents and wiki pages with version history sit next to the boards, so the brief lives beside the card it belongs to. Permissions follow roles, set in one admin area. Taskora is cloud-hosted out of the box, and self-hosted deployment on your own servers is available on request via hello@taskora.ai.

If you're weighing whether this structure fits your team's mix of work, the use cases page shows how product, ops, and marketing teams each run the same workspace.

Start with one stream

Everything in this guide runs on one flat plan. It's $13 per seat per month billed monthly, or $10 per seat per month billed yearly, with every feature included. Flat pricing, no feature tiers, so the workflow tools aren't gated behind a higher plan.

Free to start until November 1, no credit card required. Try Taskora free. That's long enough to run every step in this guide before you pay anything.

FAQ

What is a custom kanban status workflow in Taskora?

It's the set of statuses you define for a stream's kanban board, with one start status, one final status, and the allowed transitions between them. Each stream carries its own workflow, so two teams in the same workspace can work differently.

Can different streams have different workflows?

Yes. An editorial stream and a client delivery stream can run different statuses and transitions side by side in the same workspace.

How many statuses should a kanban workflow have?

Four to six is a good starting point. Every status should be a word your team already uses in standup, and you can add one later when the board shows something is missing.

What happens if work needs to go backward?

Treat it as an allowed transition and draw it on purpose. An editorial board might allow Editing back to Drafting when review sends a piece back with notes. Cards then follow the path you drew instead of sneaking past it.