Why Bitrix24 document flow breaks on approvals
Document flow in Bitrix24 breaks not at the start of the route, but in the middle of contract approval.
The approval task is created correctly, but hangs at a specific step: the approver has gone on vacation, no substitute is appointed, and the deadline is not escalated to anyone. A week later, the deal is stalled and the client is waiting for signing.
The second failure point is document versions. Edits arrive as an attachment in a comment or by email, rather than as a new version in the card, so three files with the same name end up in circulation.
The reason is that the print template is not tied to the business process stage: the revision number is not recorded anywhere, and losing document versions becomes the norm.
Third, the approval rhythm depends on a person. They go around chats, nudge approvers, and manually move deadlines. While there are five contracts, this works; in a high-volume flow, manual reminders turn into a separate job, and the one who wasn't nudged is bound to be missed.
The cost of such a scheme is a stretched approval cycle: the deal ages, terms are revised, and the manager, instead of making substantive decisions, is engaged in dispatching. Next, we look at how this is closed by setting up routes, templates, and permissions.
What changes after implementing approval routes
Reduction of the approval cycle
A document is launched not by email, but by a template: the route is predefined, so the author immediately sees to whom and in what sequence the file will go.
The approval time becomes measurable — for each stage, you can see how long it took and who it was delayed on, and the responsible person receives a task in the system, not a reminder in a chat. This removes the main source of downtime: the document no longer waits for someone to remember it.
Standard routes — contract, invoice, memo, payment request — are configured once and then launched from a template.
If a new approval branch is needed, for example when the amount is above a threshold or the counterparty changes, it is added to the template rather than reassembled manually for each document.
Version registry and transparent statuses
A single document registry replaces folders, attachments, and email threads: each card has an owner, current stage, and deadline.
Version control is built into the process itself — an edit does not overwrite the previous approval but creates a new version while preserving the comment history and the set of approvers.
Transparent statuses mean that any participant sees where the document is now and what will happen to it next, without clarifying emails.
Document assignments live in the same place: they are issued directly from the card, tied to a specific version, and closed upon completion. As a result, the manager receives not a manually compiled report but a snapshot of stage deadlines and route bottlenecks.
Bitrix24 document flow formats and their limitations
The choice of format in Bitrix24 is determined by how many document types the company has and how heterogeneous the rules for their movement are.
Standard routes cover typical "from point A to point B" scenarios, while customizable processes in cards cover everything that requires condition-based branching and links to other portal entities.
Standard approval routes
The standard loop works on top of document templates: for each type, the sequence or parallelism of approvers, deadlines, delegation rights, and signing are defined.
The limitation is that the route is effectively linear: it does not branch by counterparty type or amount, does not read fields from related cards, and almost does not trigger automatic actions on the document.
On the other hand, it is predictable, visible directly in the document interface, and access rights are inherited from the portal.
Processes in cards
If the rules differ for branches and contract types, the route is assembled as a process in the card: transition conditions, robots, task creation, updating related records.
The external signing loop is connected as a separate step, and here it is important to determine in advance which system remains the source of truth for status — otherwise the statuses in the portal and at the counterparty diverge, and accounting receives a document without a signing mark.
| Option | When it fits | Limitations |
|---|---|---|
| Standard route by template | same-type documents, uniform rules for everyone | linear logic, no conditions or external calls |
| Process in the card | different rules by department and contract type | more expensive to maintain, requires describing and testing branches |
| Hybrid: template plus process | standard approval with individual branches | dual permission settings, template version control needed |
| External signing loop | working with counterparties and legally significant exchange | some statuses live outside the portal, synchronization needed |
Implementation procedure: from approval audit to handover
The work procedure is fixed: first we describe how approval is currently structured, then transfer it to routes and put it into production after testing on real documents.
This way, the regulation does not have to be rewritten on a live flow when signed invoices are hanging in an unfinished route.
- Audit of regulations. We collect document types, participants, and actual approval times: who prepares, approves, signs, and what happens upon rejection. The output is a table with the current path for each type and bottlenecks such as approval in chat.
- Route diagram. For each document type, we draw the path: sequential and parallel branches, transition conditions, deadline per step, escalation if the approver is silent. We approve the diagram before configuration — editing on paper is cheaper than redoing a launched process.
- Document access rights. We assign roles by function, not by name: initiator, approver, signer, observer, route administrator. When an employee is transferred, access changes with the role, and the approval history is preserved.
- Templates and cards. We define required fields, numbering, automatic substitution of details from the accounting system, and linkage to the counterparty. Filled fields eliminate manual entry and repeated data requests.
- Test run. We run documents from the previous period: incoming, contracts, memos. We look at where the route stops, which fields are missing, how escalation works, and fix before enabling.
- Handover to operation. We provide the regulation, role-based instructions, and the route diagram, and show the administrator how to add a step or change an approver. We support and handle requests during the first month.
The set of settings and documentation that remains with you
The result of configuration is not a process that lives in the administrator's head, but a set of artifacts in your environment.
It survives a change of responsible person, the arrival of a new employee, and a change of contractor: the route logic can be restored from documents without taking the portal settings apart again.
- Route map. All approval branches with participant roles, transition conditions, and deadline at each step — you can see where the document gets stuck and who is holding up the stage.
- Access matrix. Correspondence of positions and rights to sections, folders, reference books, and reports: when an employee is transferred, rights change in one place, not in ten.
- Document templates. With automatic detail substitution, versioning, and required fields — a document with unfilled key details does not go for approval.
- Escalation regulation. What to do if the approver is silent longer than the deadline: reminder, transfer to a substitute, notification to the manager — and after how much time each step triggers.
- Instructions for employees. Scenarios for each role — create, approve, return for revision — with interface screens, not general wording.
- Edit procedure. Who adds a new route, stage, or field and how it is recorded in the log, so that the diagram does not diverge from the settings after the very first modification.
We provide documents in editable form: you can supplement them on your own without requesting every edit.
Case study: contract approval cycle reduced threefold
Contract approval is a regular process with predictable stages, but it depended on people, not rules. Lawyers, finance, and the manager received attachments with different edit dates, and the current version had to be clarified by phone.
Of nine steps, six depended on manually moving edits, renaming files, and the secretary's reminders.
How it was before the changes
On average, the approval cycle took 11 business days, every fifth contract went to the counterparty in a version without the latest edit, and deadlines were missed in 20% of cases.
The lawyer's workload depended on who first noticed the stalled document and whether they managed to reach the approver by phone.
What was changed and what was achieved
Routes were assembled in Bitrix24: each contract type has its own set of stages, deadlines, and responsible persons, and the template substitutes details and assembles the document card.
Edits are made in a single file with version history, the status and current assignee are visible in the card, and reminders and overdue escalation are sent automatically.
The approval cycle was reduced to 3-4 business days, and the share of manual operations is about 15% (loading incoming documents and final signing).
The number of contracts per month increased with the same headcount, disputed versions disappeared, and missed deadlines dropped to 3%.
How a document template differs from an approval route
These are two different levels of configuration, and one does not replace the other. A template describes what a document consists of: required fields, substitution of data from the card, print form, and viewing rights.
A route describes what happens next: who checks the document and in what sequence, how much time is allotted for it, and what triggers when the approver is silent.
| What we compare | Document template | Approval route |
|---|---|---|
| What it defines | Field composition, details, print form | Steps, roles, deadlines, transition conditions |
| What it provides | Uniform document appearance without manual entry | Visible status: who has the document and how long it has been there |
| When it changes | When the form or details change | When the regulation and responsibility levels change |
A single template is sufficient when the process is linear: a request of one type, one approver, and the decision is recorded by a status change. Here, the template, access rights, and notification cover the task entirely — a route would add more settings than benefit.
A route is needed when branches and roles appear. The request type changes the set of approvers, some checks run in parallel, the manager has a deadline after which the task goes higher, and a substitute is assigned during absence.
A role is the key unit of configuration: one person has the right to approve, another only to view, and a third to return for revision with a comment.
In practice, they are linked: the route references the template, and a launched process follows the form version fixed at the start — editing the template does not break current approvals. First, the document composition and roles are fixed, then the transition diagram is drawn.
Technical questions asked before the start
Before the start, clients ask the same questions: what will happen to the history of past approvals, whether external signers can be connected, whether permission flexibility is sufficient, and what to do for those who are not in the Bitrix24 portal. Below are short answers that determine the scope of work and the implementation procedure.
Will you transfer the approval history?
Yes. We export document cards, file versions, resolutions, and timestamps, match authors by email, and load the records into the new environment.
The history remains tied to the route: for each document, you can see who approved at which step, not just "the file was accepted."
Can external counterparties sign?
Yes, without an account in the portal. For them, we configure a link to a specific document with a limited validity period, confirmation by a code from an email, and the right only to view and sign — other sections are closed to them.
How are access rights differentiated?
We tie rights to a role in the route, not to a person: an approver sees only their documents, a manager sees their block, and the security service sees sections with restricted markings.
A change of position or an employee leaving does not break the scheme — it is enough to move them to another role.
Is it mandatory to work inside the portal?
No. The decision is made directly from an email or mobile app, and the response is recorded in the card with the same set of attributes as when working in the interface. For the warehouse and production, we configure confirmation with a short code — no portal login is required.
Let's discuss routes for your regulations and roles
An approval route is built not "in general" but for a specific regulation: who initiates the document, who approves, at which step lawyers or finance get involved, and what happens upon rejection.
Therefore, before starting, it is important for us to align on your roles and control points — otherwise the scheme will look good but won't work.
What is worth preparing for the conversation:
- A list of standard documents — contracts, invoices, requests, memos — with the frequency and volume of each.
- The current approval regulation: participant sequence, deadlines per step, who has the right to return the document for revision.
- A role matrix by department: initiator, approver, observer, route administrator.
- Current bottlenecks: where the document hangs, how many times it is forwarded manually, which steps are duplicated.
- Accounts and access rights, including external counterparties involved in the routes.
- Requirements for the archive and reporting: retention periods, required snapshots by status and assignees.
- Launch order: what should go live first and what we move to the second stage.
After the conversation, we will return with an implementation plan: the order of configuring cards, templates, and routes, an estimate of timelines by stage, and a list of what needs to be prepared on your side before the start.
Describe the task — a call or correspondence — and we will put together an estimate for your regulations.