Business trip approvals in Bitrix24: where the process breaks
A business trip request most often originates not in the system but in a chat. An employee messages their manager, duplicates it by email to accounting, attaches a scanned invitation — and from there the document lives in someone's inbox.
Such a request has no status: it is unclear who currently has it, whether it has been approved, or whether it has been returned for revision.
The approval route, meanwhile, lives in the administrator's head. Department manager, financial controller, director — the chain is built correctly, but as soon as one participant goes on vacation or travels, the request stalls: there is no substitute, no escalation, no reminder. Manual approval relies on someone calling in time and asking them to take a look.
The cost of such a scheme is approval delays of several days while trip deadlines are burning. An employee cannot confirm a booking, accounting receives closing documents retroactively, and the advance report is assembled manually from chats.
Some business trips are canceled simply because the decision came after the departure date — and no one canceled the tasks themselves.
In Bitrix24, this is covered by standard tools: a business trip request becomes an element of the process, the approval route is defined by roles, and the status is visible to all participants in real time. Below, we break down exactly where the process breaks and how it is covered.
What changes after implementation: timelines, transparency, expense control
It makes sense to evaluate such an implementation by three measures: how long a request takes to reach a decision, how many manual actions disappear for accounting and managers, and what deviations are caught before the trip rather than after.
In Bitrix24, this is visible in the log: each request records the submission time, every approval, and the final decision — and these are what "before and after" measurements are built on.
Approval time is compressed by a route instead of correspondence. The request immediately goes to the right manager, then to accounting and the security service — in parallel where checks are independent, with reminders and substitution during the approver's absence.
A decision on a standard business trip is made within one business day, rather than after a series of calls and email clarifications.
Transparent statuses remove the main reason for manual clarifications. The employee sees whose step the request is on, the manager sees the change history and the trip justification, and accounting sees what has been confirmed and which documents are already ready. Some "where is my request" inquiries disappear: the state is readable right in the card.
Business trip expense control shifts to the request stage — limits by destination and category, checking advance balances, and prohibiting retroactive submission.
Accounting no longer needs to ask again about the trip composition, dates, department, and expense item: documents are assembled from the card, and approved data goes into the accounting system.
The result is measurable: approval time is measured in hours instead of days, the share of requests returned for revision falls, and manual operations for accounting and managers decrease noticeably.
Ways to automate routes and their limitations
The standard out-of-the-box approval route in Bitrix24 covers linear scenarios: request → manager → accounting → HR.
As long as the policy fits into a fixed sequence, ready-made business processes and customizable request templates are enough, and support comes down to editing reference data and the list of approvers.
As soon as conditions and route branches appear — a trip cost threshold, a foreign destination, a special procedure for remote employees — the ready-made scenario starts to be bypassed manually: the approver receives tasks that do not concern them, and the decision on the request lives in correspondence.
Customization for the policy moves these rules inside the process but raises the cost of maintenance: branches need to be tested and rechecked with every platform update.
| Option | When it fits | Limitations |
|---|---|---|
| Ready-made route on standard settings | Linear approval with 2–4 participants, a single policy for all departments | No branching by cost and trip type; changing the policy requires manual reconfiguration |
| Request templates and automatic actions without customization | Conditions by fields: trip type, department, auto-filling approvers | Logic is limited to the provided conditions; parallel branches and returns for revision are partially covered |
| Custom logic for your policy | Multi-level conditions, limits, approval with accounting and the accounting system, recording every step | Regression checks are needed for updates; without a diagram and documentation, the route is hard to hand over |
The choice here is a compromise between speed of launch and precision in following the policy. Neither option removes the need to describe the policy itself: automation reproduces rules, it does not invent them for you.
Implementation stages: from process analysis to handover
First, we analyze how business trip approval currently works: who initiates the request, what documents are attached to it, who approves and on what basis, and where the route gets stuck.
The output is a process map with roles, timelines, and control points, agreed with you before setup begins. Only after that do we touch the Bitrix24 configuration.
- Approval process audit — interviews with initiators, accounting, and managers, analysis of current emails and spreadsheets, and recording bottlenecks and manual operations.
- Route diagram — participant roles, branching conditions (trip type, department, exceeding a limit), deadlines at each step, and the scenario for rejection and returning a request for revision.
- Request setup — a form with required fields, an approval business process, robots for reminders and escalation, access rights by department, and linking the request to tasks and the calendar.
- Reference data integration — employees, departments, counterparties, and expense items are pulled from the accounting system so that data is not entered twice and reporting reconciles.
- Testing on real data — we run standard and edge-case scenarios: a trip by one employee, a group, cancellation after approval, manager absence, and a retroactive business trip.
- Handover to operation — training for initiators and approvers, role-based instructions, handling inquiries in the first weeks, and fine-tuning the route based on actual use.
Then comes support: limits, structure, and rules change, so we make edits to the route without stopping approvals.
Policies, route diagrams, and instructions for employees
After implementation, you are left not only with a working route but also with a set of documents that lets the process be changed without a developer. We hand it over in editable form — inside the system, not in correspondence with a contractor.
- Request route diagram — a process map with all branches: who approves at each step, under what condition the request goes up, what happens on rejection and when a deadline expires.
- Approval policy — timelines for each stage, limits after which financial control is engaged, the procedure when a manager is absent, and rules for replacing an approver.
- Instructions for employees — short guides with screenshots: how to create a request, attach documents, view the status, and withdraw it before calculations begin.
- Access rights and roles — a matrix: who sees only their own requests, who approves, who edits the route, and who works with the archive in read-only mode.
- Request archive and history — where attachments and statuses are stored, how to see who changed a decision and when, and how to export a selection for accounting and audits.
- Route change log — how to add an approver or change a limit on your own, without editing code or contacting us.
- Acceptance checklist — a set of test requests that checks dead ends, duplicate approvers, and notification correctness.
This set is enough for a new employee to understand the process in a day and for the route to remain manageable when the org structure changes.
Case study: request path cut from a week to one day
What it was like before automation
A manufacturing company with a distributed team: approvers and managers in different cities, and employees traveling almost every week. A business trip request traveled by email with an attached file, followed by forwards in a messenger and phone reminders.
Approval time stayed at 5–7 business days, and some inquiries settled in email threads and surfaced only after the employee returned.
They counted from the request log, without smoothing: out of sixty inquiries in a quarter, eight never reached HR or accounting at all.
Each approved trip required four manual reconciliations — dates against the shift schedule, the limit against the destination budget, ticket cost against the request, and the advance report against the actual trip.
What was changed and what the result was
We assembled an approval route in Bitrix24 on business processes: a form with required fields, automatic determination of approvers by role and destination, limit checks right at submission, and escalation of overdue items with a reminder to the manager. Every step is recorded in the request card — you can see who, when, and with what decision.
After launch, two confirmations remained instead of nine steps, and the timeline became one business day. Lost requests disappeared as a category: an inquiry is visible in the registry until closure and cannot hang without an owner.
Manual reconciliations came down to monitoring a single registry, because data about the trip, expenses, and advance report is in one card.
What to do if business trip requests already go by email
The process is not stopped for the transition: requests continue as they were, but they gain a second, managed entry point.
An email to the shared mailbox arrives in Bitrix24 through the mail gateway, is parsed by a subject and body template, and becomes an element with a number — route, dates, participants, department.
The author receives a reply with the request number and a link, and the mailbox address remains operational — the parallel operation of two entry points does not force anyone to relearn.
Next comes migration of open requests — moving what is already in progress out of email.
The mailbox is exported as a snapshot, threads with an open status are selected, and each is linked to a card: fields are filled in, correspondence and attachments are filed into comments, and the owner and approver are set according to the actual state.
There is one sign of a correct migration: the request has not lost completed steps, and the approver sees it in the same place as the others.
A phased transition is done in waves: first one trip type or department, then the next.
The criterion for closing a wave is the share of requests that completed the route without manual field edits and the time from submission to approval; if it is no worse than email, the scope is expanded.
Moving away from correspondence happens step by step: first an auto-reply informs, then email becomes a registration channel — the request is created, and work continues in the card.
The inbox is monitored with a counter of unprocessed emails; when it stays at zero for several business weeks, email approval is disabled. If a wave goes wrong, a routing rule returns the step to email without losing collected data — the rollback does not break open requests.
Technical questions: access rights, substitution, integrations
We build access rights from the organizational structure, not from one-off wishes: user groups, roles at the level of card stages and fields.
An employee sees their own requests and their status, a department manager sees their own scope, and accounting sees only what has reached calculation. The access matrix remains in the project documentation, so when areas of responsibility change, it is not rebuilt from scratch.
Integration with the accounting system covers the HR scope: departments, positions, and managers are pulled on a schedule, with matching by employee ID. Moving an employee to another department immediately changes their route — no manual edits are required.
An approver quit or is on vacation — will requests stall?
No. If the responsible person is unavailable, a substitution rule kicks in: the deputy from the card or a manager one level up, plus a notification to the process administrator.
We set a waiting period — after it, the request goes further up the route instead of "sticking."
The policy changed — will the process have to be redone?
The route is described as a configurable diagram: stages, conditions, and approval levels are moved into separate rules. You can add a stage or replace an approver without stopping the process, the diagram version is saved, and already launched requests follow the previous route.
Where is request history stored and who sees it?
Each request leaves a complete trail: who changed the status, when, and with what comment, including rejections and resubmissions.
The history is visible to route participants and the administrator, export to the accounting system preserves the link to documents, and the retention period is set by a separate policy.
What to send us to get an estimate and work plan
An estimate based on a description in chat almost always diverges from reality: half of the approval logic lives in exceptions that are remembered only during setup.
That is why we ask for one short set of source data — it is usually enough to calculate the scope of work without extra clarification rounds.
- Org structure diagram: departments, managers, and who substitutes an approver during vacation or sick leave.
- Approval matrix: how many levels, under what conditions the second one is engaged, where approval is parallel, and where it is strictly sequential.
- Current procedure: business process routes, robots, or rules in Bitrix24, and if approval is done by email and spreadsheets — screenshots and an export.
- Business trip card composition: which fields are required, which attachments are added (invitation, program, bookings), and what must be visible in the printed form.
- Policy and typical exceptions: retroactive business trips, urgent ones, cancellation and rescheduling of an already approved request.
- Roles and rights: who initiates, who sees only their own requests, who is notified without decision rights, and who has access to history and exports.
- Integration points with 1C and the calendar: payments, advance report, and employee availability on the trip dates.
- Access to a test portal scope or readiness to provide it — we check the logic on real roles, not demo data.
If some data is missing, that is not a stop: we close the gaps during a task discussion, which takes 30–40 minutes. Then we return with a project estimate, implementation timelines by stage, and a work plan with control points.
The composition of routes, fields, and roles is recorded in writing so that acceptance follows an agreed list rather than memory.