Is there a limit on the number of statuses?

No — create as many as your process needs.

Can I reorder statuses on the fly?

Yes — drag and edit statuses any time.

Are my statuses visible to teammates?

Yes — all project members see the same statuses on the board.

Can I have different statuses in different projects?

Yes — each board is configured independently.

All features

Statuses

Custom statuses for your workflow

Create your own statuses for any board — no system limits. Pre-built templates for marketing, dev, sales, and CRM out of the box.

Built for

Product teams
Engineering
Marketing
Operations

Try Now See pricing

Board · Sprint 24

Backlog4

Refresh hero

Pricing v2

Mobile menu

Footer links

In progress3

Checkout flow

Onboarding tour

Search bar

Review2

Auth refactor

CMS schema

Done3

Brand refresh

CMS migration

Analytics setup

By the numbers

15+

ready-made templates

Easylim CRM

∞

statuses per board

customer data

100%

no-code customization

2025 survey

Templates per industry

Pick a direction and see how a status board looks for that real-world process.

Marketing

Content management

Track content creation at every stage.

Advertising

Run campaigns step by step.

Social media

The whole SMM flow in one place.

Engineering

Sprint

Manage sprint tasks Scrum-style.

Engineering

Standardize technical processes across the team.

Website management

Transparent work on the site: redesign or updates.

Business

Startups

Structure product development.

Corporate teams

Keep work transparent across large teams.

E-commerce

Run an online store smoothly.

Personal

Vacation

Organize personal plans and downtime.

Event planning

Plan events and meetings.

Job search

Track your application pipeline.

Sales

Full sales pipeline on one board.

Freelance

Organize freelance work.

CRM

Manage customer comms.

Deep dive

Custom statuses — how to design a workflow your team actually uses

5 chapters

"To Do / In Progress / Done" isn't a workflow — it's a starting screen. Real work has many more states: waiting on design, waiting on legal, bounced back from QA with a bug, cancelled by the client. If you hide all of that under a single "In Progress", the lead can't see where work actually stands. <strong>Custom statuses</strong> in Easylim let your workflow match reality. Below: how to design them so you don't end up with 25 statuses nobody understands two weeks in.

Розділ

What a custom status is — and why three defaults aren't enough

A custom status is a stage of your real workflow expressed as a column on the board. Marketing doesn't work like engineering; support doesn't work like sales. Universal "To Do / Done" hides specifics — and that's exactly where the truth about a task's real state gets lost.

Why three defaults aren't enough: when a task sits in "In Progress" for a week, you don't know what's happening. Is the assignee working on it? Waiting on something? Blocked? Custom statuses answer instantly. "Waiting on design" — not the assignee's problem, it's the designer's. "Waiting on client" — not our bottleneck. "Blocked by legal" — needs escalation.

In Easylim you can run different status sets on different boards inside one project: the engineering sprint board uses "Backlog → In Progress → Code Review → QA → Released"; the sales board in the same workspace uses "New lead → Contact → Demo → Negotiation → Closed-won/lost". That's not two tools; it's one system.

Default statuses hide reality. Custom statuses surface it.
"Waiting on [X]" is the single most useful status — it exposes external blockers.
Different boards → different status sets. Don't mix engineering with sales.

palette · 7 custom statuses

Idea

Brief

Design

Review

Waiting client

Approval

Live

+ add status

color = meaning · red = blocker, green = done

Розділ

How to design a status set — examples for marketing, engineering and support

The biggest mistake is creating 15-20 statuses "to cover all cases". The team won't remember the difference between "In Progress", "Working on it" and "Actively developing". Two weeks in, everyone uses "In Progress" out of habit — and your custom workflow is dead. The working range is 5-7 statuses per board.

Marketing (content): "Idea → Brief → Draft → Review → Waiting on brand → Published". Six statuses, each with a clear entry condition. Engineering: "Backlog → In Progress → Code Review → QA → Waiting on release → Released". Support: "New → Triaged → Waiting on customer → Waiting on backend → Resolved". Sales: "New lead → Qualified → Demo → Negotiation → Closed-won / Closed-lost".

The "Waiting on [X]" principle is the most valuable move. Instead of a single "In Progress", split it into "Waiting on client", "Waiting on QA", "Waiting on design", "Waiting on legal". Now at standup the lead doesn't see "3 tasks in progress" — they see "1 in progress, 2 waiting on client". The action is different: ping the client, don't pressure the assignee.

5-7 statuses per board is the ceiling. More than that and the team gets confused.
Every status needs a clear entry and exit condition.
Separate "Waiting on [client/design/legal]" = instant visibility of external blockers.

status editor

edit statussaved

name

Waiting on client

color

type

To do

Active

Done

WIP limit6

Розділ

Transitions, colors and WIP limits — what makes statuses actually work

Transition rules define which statuses can move where. Without them, someone will drag a card from "Backlog" straight to "Released", skipping Code Review and QA. In Easylim you can block illegal jumps: "Backlog → In Progress only", "Code Review → QA or back to In Progress", "QA → Released or back to Code Review".

Colors and icons aren't decoration — they're fast scanning. Red for "Waiting on [X]" because it's a blocker. Yellow for "Code Review" — needs attention. Green for "Released" — all good. The team looks at the board and understands where action is needed in 2 seconds, no reading required.

WIP limits per status: "In Progress" — at most 1.5× the team size. Four engineers → limit 6. Try to add a 7th and Easylim warns. "Code Review" — limit 4-5: when the queue grows beyond that, new work has to be paused so the reviewer can catch up. It doesn't slow the team down; it surfaces real capacity.

Status-driven automation: when a task moves to "Code Review", a reviewer gets assigned automatically; on "QA", a subtask checklist appears; on "Released", a Slack message fires into #releases. That's 80% of engineering discipline without anyone having to think about it.

Transition rules = protection against chaos. Don't allow skipping stages.
Colors with meaning (red = blocker) — board readable in 2 seconds.
WIP limit on "In Progress" = 1.5× team size.

cards per status · sprint 24

Backlog

In progress

wip 5/6

Code review

wip 5/4

Waiting client

Released

total 45 · liveflow: ⚠ review queue

Розділ

What a week with custom statuses looks like in an engineering team

Monday 10:00 — standup. The lead doesn't look at "what are you doing" — they look at the "Waiting on [X]" columns. "3 tasks waiting on client — Elena will ping by 2pm", "2 waiting on design — Sam, when?". The team doesn't say "all good on my side" — the system shows reality.

Tuesday — blocker triage. The lead opens the "all tasks in Waiting*" filter and goes through them. Waiting on client → ping their channel; legal → escalate to the CEO; design → sync with the designer. This isn't "I'm reminding you for the third time" — it's systematic blocker work.

Wednesday — unblocking Code Review. The "Code Review" column has 5 cards (limit 4). The team pauses new work and helps clear the queue. Different culture: "unblock first, then pull new". Two or three weeks of this and team velocity climbs 20-30% with no headcount added.

Friday — retro on stuck tasks. The lead opens "in status for more than 7 days". Each card is a story. Why did it get stuck? What do we change so it doesn't repeat? Maybe rename "Waiting on client" to "Waiting on client Acme" — because Acme is systematically the bottleneck.

Standup = scan "Waiting on [X]" columns, not "what are you doing".
A column with a WIP limit makes the team stop new work themselves.
Filter "in status > 7 days" = automatic zombie-task detector.

3 teams · 3 workflows · 1 workspace

Marketing5 statuses

Idea

›

Brief

›

Design

›

Wait brand

›

Live

Engineering5 statuses

Backlog

›

In prog

›

Review

›

Released

Support5 statuses

New

›

Triage

›

Wait cust

›

Wait dev

›

Resolved

Розділ

When custom statuses aren't worth it — and what to use instead

If your team handles simple tasks without stages (personal to-dos, a basic ticket tracker, your grocery list) — the default "To Do / Done" is fine. Custom statuses here create bureaucracy without payoff: thinking each time about which status to use is pure overhead.

If what you want to control is time, not state — custom statuses won't help. A card can sit in "In Progress" for a day or a month. For that you need a Gantt chart with dates or a calendar with time slots.

If tasks automatically progress through stages (an email ticket → auto "New" → agent assigned → auto "In progress") — that's not custom statuses, that's workflow automation. Set it up via automation or Zapier-style integrations.

General rule: under 4 real workflow stages → defaults are enough. 5-7 → custom statuses pay off big. 10+ → you've designed it wrong, split it into two boards.

Personal to-dos, simple tickets → default statuses, no customization.
Time control, not state control → Gantt or calendar.
More than 10 statuses = bad design. Split into two boards.

status vs tag · don't confuse them

Status

one value · workflow stage

Backlog

In progress

Review✓ current

Done

Quick takeaways

15-7 statuses per board. More than that → dead workflow the team ignores.
2"Waiting on [X]" is the most valuable status — it surfaces external blockers instantly.
3Transition rules + colors + WIP limits = a working process, not decoration.
4Over 10 statuses → split into two boards with different sets.

Integrations