Kanban in Bitrix24: how to manage tasks with robots and WIP limits

Setting up Bitrix24 Kanban boards: where the task flow breaks

A Kanban board in Bitrix24 looks workable right up to the moment when thirty cards are simultaneously sitting in the “In Progress” stage.

The assignee takes on everything at once, deadlines slip, and the manager learns about the problem only after it is overdue — flow transparency remains only on paper.

The cause is usually configuration, not people. Stages are created “by eye,” transitions between them are limited neither by a limit on simultaneously open cards, nor by required fields, nor by automation rules.

Statuses are set manually: the assignee finished the work but did not move the card — and the task is lost between stages, while the team's actual workload is distorted.

A separate problem is the pileup of tasks at the entrance and at the end of the funnel. Cards accumulate in “New” and “Under Review,” stuck tasks are not highlighted, and the time spent in each stage is not measured anywhere.

The bottleneck in such a flow is invisible: it seems the assignee is slowing things down, although in fact the input information is not ready or approval is lacking.

We break down how this is addressed by configuring Bitrix24 Kanban boards: limits on the number of cards in a stage, robots for transitions, required fields when a task moves, and a report on time in stage. Each setting treats a specific class of failure rather than merely decorating the board.

The effect of restructuring the flow: deadlines, losses, transparency

The first measurable effect is task lead time. A WIP limit on a column allows strictly a specified number of cards to be kept in progress: a new one does not enter until the previous one has left the stage.

The flow levels out, queues disappear where a task waits for an assignee longer than it takes to complete, and lead time becomes predictable instead of “however it turns out.”

The second is lost requests. Each request exists as a card with a stage, an assignee, and a deadline, and the Bitrix24 robot resets the deadline when moving between stages and reminds about a stuck card.

A request with no movement for a week is visible on the board rather than dissolving into correspondence: the number of lost requests goes to zero, because there is simply nowhere for a task to get lost.

Employee workload stops being a matter of guesswork. On the board you can see who has five cards in progress and who has two, who is dragging overdue ones, and where a queue is building.

Overload is noticed before a deadline is missed, and there is time to redistribute work within the team — without emergency rushes and manual calls.

From the same data grows a deadline forecast: the average rate at which cards leave a stage gives an estimated completion date. Instead of “we'll try by the end of the week,” the manager sees when the task will actually reach a result and which bottleneck is shifting that date.

Task presentation formats: what to choose for your process

A simple board is stages without required fields: a card is dragged between columns, and the status changes manually. It is used for a short flow and a team of up to five people, when the value is in workload visibility rather than control.

There is one limitation: the number of cards in a column is unlimited, so “In Progress” grows, and the assignee switches between tasks more often than completing them.

Kanban with limits adds a counter on the column: the board does not allow placing a card beyond the norm, and transition robots fill in the assignee, deadline, and notification.

The Scrum view builds on a task list, sprint, and burndown chart — needed where pace matters more than daily flow. A smart process is a separate entity with its own fields, stages, and permissions: for requests and deals, not for ordinary tasks.

What each option covers

Switching the view does not recreate data: tasks, stages, and fields are shared; only the rules change. Board templates lock in the column structure, permissions, and automations, so a new project is launched from a copy rather than assembled from scratch.

Implementation stages: from flow audit to handover of regulations

Configuring Bitrix24 Kanban boards begins not with dragging columns, but with analyzing how the task flow moves now.

The order of work is fixed: first measurement, then the stage scheme, and only then automation — otherwise robots lock in existing bottlenecks and have to be redone.

1. Task flow audit. We export history by stages: how long a card sits in each column, where the bulk accumulates, who most often moves things back. The output is a list of bottlenecks with numbers.
2. Stage scheme. We assemble columns for the actual work steps: what to separate, what to combine, which stage to make final with automatic closure. Here we also set WIP limits — the maximum number of simultaneous tasks per assignee.
3. Robots and triggers. For each stage we assign a robot: creating the next task, notifying the client, changing the assignee, stage deadline. We tie triggers to board events — the transition fires when the stage changes, not manually.
4. Transition rules. We define required fields, prohibit skipping stages, and delineate permissions: who moves a card, who only views. The board stops depending on a single administrator.
5. Acceptance check. We run the loop on real tasks — from creation to closure, with returns and rejections. We look at where a robot did not fire, where the limit hinders what is needed, and adjust before handover.
6. Handover of regulations. We provide the board scheme, a map of robots and triggers, a memo on required fields, and an administrator checklist. Plus brief team training so the rules live rather than remain in a document.

Project artifacts: flow scheme, rules, instructions

After the project is delivered, you are left not with a set of screenshots of “how it was configured,” but with a working kit that lets you develop the board on your own.

We record not only the current state but also the logic of decisions: why these particular stages were chosen, where responsibility boundaries lie, and what will happen to automation if the process changes.

Using these documents, a new administrator or department head can onboard an employee and edit settings without contacting us.

• Kanban board scheme — a list of stages, their sequence, WIP limits for each column, and the conditions under which a task is considered completed rather than merely dragged.
• Access rights matrix — which roles create tasks, who moves cards, who changes reference books and stage settings; operations available only to the administrator are marked separately.
• Task handling regulations — what the assignee does if a task sits in a column longer than the agreed period, where a blocker is escalated, and who removes the limit during overload.
• Automation map — at which stages robots and triggers are attached, which fields and assignees they change, and what actions they perform on error.
• Employee instructions — a short document covering 4–6 scenarios: task creation, taking into work, handoff, closure, return from review.
• Maintenance checklist — regular checks: growth in the number of cards in a column, tasks without movement and without an assignee, duplicates, robots that fired with an error, and discrepancies between actual stages and the scheme.
• Change log and rollback points — the working configuration is saved before every edit, so an unsuccessful change is rolled back to the previous state in minutes.

Case study: how lost tasks were eliminated and deadlines shortened

A project with two work streams: requests from business units and internal product improvements. Both went through one board — requests, incidents, approvals, and technical debt sat in shared columns.

There were no limits, transition robots were not configured, so cards accumulated in the “in progress” and “under review” statuses and went into the report as stuck.

What it was like before restructuring

The median task lead time was 19 working days, and almost a third of tasks sat for more than two weeks without movement. Overdue tasks with deadlines were about 40%, while two assignees simultaneously held 14–16 active cards each.

Tracking was mixed: a client request, an improvement, and an internal task were counted under one metric, so the manager could not see exactly where time was lost.

What was changed and what was achieved

The streams were separated into different projects, each with its own stages and transition rules.

In Bitrix24, a limit was set on the “in progress” and “under review” columns, and robots took over the routine: auto-filling the assignee and deadline, removing the task from the assignee upon transfer, reminding and escalating if a card sits unchanged for more than three days.

Overdue tasks go into a separate selection and are reviewed at a weekly sync rather than surfacing at the end of the month.

As a result, median lead time dropped to 11 working days, and the share of stuck tasks fell from 25–30% to 5–6%. The number of overdue items dropped by roughly three times.

Workload leveled out: the limit prevents taking a new task until the current one is closed, so variance across assignees decreased, and overload is visible right on the board rather than from quarterly results.

Technical concerns: limits, roles, reports, integrations

Kanban in Bitrix24 is rarely “just a board”: it relies on stages, role permissions, robots, and reporting, and a miscalculation in one layer surfaces a week or two later — tasks pile up in one column, some employees see extra deals, and the manager cannot compile a workload snapshot. Below are the things most often clarified before work begins.

How do access rights combine with roles in departments?

Rights are granted at the level of role, department, and stage, so the same board shows a different set of columns to a manager, an employee, and a contractor.

We record a matrix of “role — what they see — what they change” and test it on test accounts: closed deals and other people's tasks should not come into view, while an approver retains access to the relevant stage.

What reports can actually be built from Kanban?

The board provides distribution of tasks by stages and assignees, average time spent in each column, the share of tasks that returned, and workload by period.

Data is taken from stage history, so the accuracy of transition rules matters — otherwise analytics will show a distorted picture. Reports are configured for management questions, not “everything at once.”

How is Kanban linked to deal tracking?

The task board is linked to deal stages in CRM: moving a deal pulls in the necessary tasks, and closing a task moves the deal forward.

The link is configured via robots and automation rules, so it is important to agree in advance what counts as a trigger — a stage change, a filled field, or an employee action.

What happens to already accumulated tasks during the transition?

Existing tasks are transferred with statuses, assignees, deadlines, and attachments preserved; we restore stage history where it exists.

We perform the transition on a copy of the board, verify the count and statuses, and only then open it to the team — the work process does not stop.

Let's discuss the task: what to send for an estimate and plan

To come back with an estimate and work plan rather than general wording, we need a minimum set of inputs. It is enough to describe the current process in your own words — we will assemble the flow scheme, stage limits, and launch order ourselves. The more specific the inputs, the more accurate the estimate.

• Task and teams. Which departments work in Bitrix24, how many people are in each, and which task types predominate — recurring, project, or customer requests.
• Current boards. Screenshots or an export of existing Kanban boards: stages, assignees, and at which step tasks get stuck the longest.
• Board examples. If you are guided by someone else's experience, send the examples you like. We will analyze what from them transfers to your process and what will remain a pretty picture.
• Pain points. Where tasks get lost, which stages sit idle, who is overloaded. This is exactly what determines which robots and automation rules are missing.
• List of accesses. A Bitrix24 portal with administrator rights, access to 1C if synchronization is needed, and a work email for notifications and robots.
• Constraints. Internal regulations, data storage requirements, prohibitions on external services — the final scheme depends on them.
• Launch order. What is more important to close first: one team or all at once, and by what date you need a working loop.

Describe the task and attach what you have at hand — we will come back with an estimate and plan: a flow scheme, a set of robots, stage limits, and a launch order by department. We will discuss the details and agree on the next step.

How a smart process differs from an ordinary task list

An ordinary task list is a flat list with one set of fields and one status for the entire record. It covers one-off assignments and short cycles where the assignee determines the sequence of steps.

But as soon as a process becomes regulated — with required stages, approvers, and different data at each step — the list becomes overgrown with homemade “stage” fields, filters, and verbal agreements that depend on specific people.

A smart process in Bitrix24 is a separate entity with its own set of fields, stages, and transition permissions.

Its items live on their own Kanban board: each column has its own required fields, robots, and automated actions, and the card stores movement history and participants at each step.

The boundary lies in repeatability and the number of participants. If a process runs regularly, goes through more than two approvals, and requires stage reporting, the list turns into a manual register that someone maintains in parallel.

A smart process transfers the regulation into the entity itself: a stage will not allow closing a card without required data, and a Kanban board with a limit on simultaneous items shows the bottleneck before it disrupts deadlines.