Setting up document approval through Bitrix24 business processes

Document approval in Bitrix24: where the process breaks

Until document approval in Bitrix24 is built as a process, contracts and requests live in email and messengers.

A lawyer sends edits as an attachment, the commercial director replies "OK" in a chat, accounting asks for "the same version, but with a new price." No one can answer where a specific contract is right now without digging through correspondence.

This is how the document version is lost: an edit goes back into a file that has already been distributed across three copies, while a fourth one is being signed.

Manual approval by email leaves no trace of who is holding the document or how many days it has been with them — no one measures the turnaround time because there is no starting point.

Next comes stalled approval: the stage is formally in progress, the responsible person is on vacation, and the task has not been reassigned to anyone.

The contract approval route in this form is reconstructed after the fact from correspondence rather than from the portal log — and the delay is discovered from the counterparty, not from the system.

Inside the portal, this is assembled differently: the document card is linked to a deal or request, the route is defined by a business process, each step has a deadline, an owner, and a substitute, and all versions are stored in one place with a change history. Below, we break down exactly where the process breaks and how configuration closes that gap.

What changes after setup: time, control, register

Before setup, no one measures document turnaround time: it lives in email, chats, and personal folders, and the deadline surfaces only once it has already been missed.

A business process in Bitrix24 turns the route into an executable scheme — with an owner at each step, a deadline, and a reminder. The document no longer depends on whether the approver remembers their task.

Each edit is saved as a separate version: you can see who changed what, what was a comment, and what became the final wording.

The document version history eliminates disputes like "we approved a different version": any previous version can be restored, and the document returns to work from the step where it stopped, without going through the entire route again.

A single approval register replaces manual searching through correspondence: one list shows what is under review, with whom, how long it has been there, and what was rejected and why.

Status transparency works for both the initiator and the manager: the bottleneck is visible at the step where documents pile up the longest, not only when the deadline is ultimately missed.

From this comes control over execution discipline without manual reminders: for each participant, you can see the average response time and the share of overdue items, so the conversation is about numbers, not impressions.

A whole class of failures — "the document got lost in correspondence" — disappears: the system returns the task itself, escalates overdue items, and records the result.

Approval route options: comparing modes

In Bitrix24, an approval route is a business process, and its execution mode is set at the very start: sequential, parallel, or mixed.

A rigid route specifies approvers directly in the process template, while flexible rules take the participant composition from the document details — the initiator's department, the contract category, the counterparty type.

A conditional transition in the process checks the details: if the contract amount threshold is exceeded, a stage with the financial director is added; if not, the route closes with the manager.

We also include a manual intervention point separately: the administrator reassigns a task or skips a stage, but every action goes into the process history. Therefore, choosing a mode is a trade-off between approval time and route predictability.

Implementation stages: from process audit to handover

The order of work matters more than speed here: if you configure the rules first and then discover that half of the company's routes work differently, the scheme has to be redone along with permissions and already launched documents.

That is why we proceed sequentially — from analyzing current processes to handover, recording the result at each step.

1. Business process audit. We analyze how approval works now: who initiates, who approves, at which step the document most often "gets stuck," and where decisions are made by email and messengers outside the system.
2. Approval route design. We build a map of stages: sequential and parallel branches, transition conditions, deadlines at each step, escalation to the manager when there is no response, and return for revision with edit history.
3. Access rights setup. Roles and groups, visibility of the document card by department, the right to approve, the right to withdraw approval, and a ban on changing the file after approval — this way, the separation of responsibility rests on rules, not agreements.
4. Testing on real documents. We run anonymized copies of typical contracts and requests, including inconvenient cases: the approver is on vacation, the signatory is replaced, or there is a rejection at the last stage. We catch route errors before launch, not on a live document.
5. Migration of in-progress documents. We determine what to finish approving under the old rules and what to move to the new route, so as not to lose history or break cycles that have already started.
6. Handover to operation and training. We provide the route scheme, approval regulations, and instructions for employees and the system administrator, and show how to add new approvers and change deadlines without rebuilding the process.

Configurations, schemes, and regulations: what remains with you

A configured document approval route in Bitrix24 lasts only until the first staffing change: a new employee does not know which step cannot be skipped, and the administrator does not know why that particular condition is in the branch.

That is why we hand over not only a working configuration but also the layer that lets you develop it without us — everything lives in your portal, tied to specific process templates and roles, not to individual names.

• Route schemes for each document type — branching points, transition conditions, per-step deadlines, and automatic actions: notification, task creation, stage change, edit lock.
• Rights and roles matrix — who initiates, who approves, who signs off, who only observes, and who substitutes for someone absent; tied to departments and positions.
• User instructions — scenarios for each role: how to send a document, what to do when it is returned for revision, where to view the history and the current owner.
• Change management regulations — the procedure for editing the route, who approves the new logic, and how the version is tested in a test environment before being enabled in production.
• Process documentation — a map of fields, statuses, and templates plus a version log that answers what changed and why.
• Administrator kit — where settings are stored, how to transfer the process to another portal, and what to check after an update so approval does not stop.

Case study: contract turnaround time was cut threefold

At the client — a legal department and four divisions — the contract went sequentially through a chain: lawyer, finance, department head, commercial director, general director.

The cycle took from nine to twelve days, file versions diverged by email, and the question "where is the document now" was answered by calling the responsible person.

We mapped the actual route and moved it into a business process in Bitrix24: stages assigned to a role rather than a specific employee, parallel branches for the lawyer and finance, a deadline for each step, automatic reminders, and a substitution rule for vacation or sick leave.

Edits are made in the document card, not in a sent file — the approver always sees the current version.

Metrics before and after

Separately, a class of failures disappeared that was not even counted before: approval of a version that had already been replaced; a document sent to the wrong participant; a stage whose deadline no one controlled.

Now every action has an author and a timestamp, and returning a document from the last step moves it exactly to the point in the route where revision is needed — without rebuilding the chain or sending it through all approvers again.

How classic business processes differ from smart processes

The difference between the mechanisms is not in the interface but in where the document card data is stored. A classic business process is an approval scenario: it launches on a specific element (file, CRM record, information block element) and keeps state in its own instance.

A smart process in Bitrix24 is a separate entity with its own set of fields, card, stages, and access rights, like CRM elements.

Hence the difference in relationships between entities. A smart process natively links to a company, contact, deal, and other smart processes, while selections and reports are built on its fields.

A classic process is tied to one element, so a register for it is assembled manually — through lists, reports, or export.

The choice of mechanism for a task is determined by the nature of the flow. For a contract register, we use a smart process: filters by counterparty and deadline are needed, along with reporting, stage automations, and renewal reminders.

For a one-off request, a classic process is faster — there is no need to create a new entity or configure rights and a card; approval launches directly on the existing record.

In practice, a hybrid more often works: the document card and relationships live in a smart process, while the approval route inside it is launched by a classic process.

Technical doubts before starting: answering questions

Before starting document approval work, engineers and department heads ask roughly the same questions: what will happen to existing routes, whether remote employees will retain access, and how to change the scheme without stopping the department. Below are answers without generalities, as it works in Bitrix24.

Is a permanent connection to the system required for approval?

No. The task arrives in portal notifications, and the decision is made from a browser or mobile app — no separate client installation on the workstation is required.

An employee on a business trip or working remotely uses the same route; if there is no connection, the task simply waits for them to return to the system.

Can the process be changed without stopping approval?

Yes. We publish the new template version separately: running instances finish according to the old logic, while new ones start according to the changed one.

Adding an approver or editing a condition or step order does not require stopping the process and manually restarting documents.

How is access to the document itself restricted?

Rights are configured at the level of the card, folder, and stage: a participant sees only their step and the files attached to it; other sections are unavailable to them.

Downloading and printing can be disabled separately, and all actions — viewing, editing, sending — are recorded in the log with the author and time.

What happens to already uploaded documents?

They remain in the system: we launch the process for them by event or manually, pulling fields from the card — there is no need to upload the files again.

If the document already has an approval history, it is preserved, duplicates are not created, and numbering and links to counterparties are not broken.

Let's discuss the task: where we start the work

Document approval in Bitrix24 almost never comes down to a single template: what matters is who participates, at which stage, what to do in case of rejection, and how the result is recorded.

To discuss the task concretely and come back with an estimate rather than general words, a minimum of input is needed — the list below removes most of the uncertainty even before the start.

• Participant roles: who initiates, who approves, who authorizes, who receives a copy — the route scheme depends on this.
• Document types and volume: contracts, invoices, internal memos — how many items per month and what file sizes.
• Current workflow: what the route looks like now — in email, spreadsheets, or on paper.
• Branching rules: what happens on rejection, whether resubmission is required, and whether the route can be changed on the fly.
• Storage and access: where the file is stored, who sees the version history, and who is responsible for the archive.
• Integration points: 1C, email, disk, counterparties — what should receive data automatically.
• Constraints: deadlines, availability of the portal administrator, and whether processes can be changed without stopping work.

The first step of the project is analyzing this input: we compare the route with the portal's capabilities and come back with an estimate and a work plan.

In the plan, we record the scope of work by stage, areas of responsibility, and the acceptance procedure, so that before the start it is clear exactly what changes in document approval.