Setting up vacation and leave requests through Bitrix24

Vacation requests in Bitrix24: where approval breaks down

In most companies, a vacation request lives in correspondence: an employee writes in a messenger, duplicates by email, sometimes sends a paper application. While there are two approvers, the scheme works.

As soon as a second manager, HR, and payroll department appear, requests start getting lost — the email goes to the archive, the message is lost in the feed, and the person is sure the vacation has already been approved.

The manager approves blindly: they do not see the employee's remaining days, do not know who else from the department is taking those dates, and do not understand whether the direction will be left without people.

The decision is made from memory and last year's dates, not from accounting system data. Therefore vacation approval turns into a series of calls, and rejection comes after tickets are purchased.

HR closes the gap manually: transfers dates into a spreadsheet, reconciles comp time and overtime records, checks overlaps of periods, edits orders. The error is found a month or two later, when not one request but the entire schedule has to be recalculated.

We analyze how vacation requests in Bitrix24 close these failure points — from the form to automatic balance control.

Implementation effect: approval time, transparency, errors

Vacation requests in Bitrix24 stop being chat correspondence and become a record in the system. Approval follows a defined route: department manager, then HR, and when dates overlap — the owner of the adjacent direction. Oral agreements, which no one can later confirm, leave the process.

• Approval time shrinks from days to hours: the request goes to the next participant immediately after the previous decision, and the system sends a reminder to the approver itself — the document does not get stuck in someone else's mailbox.
• Transparency of balances: the employee, manager, and HR have the same picture — how many days are allotted, how many used, how many carried over. The balance is calculated from the schedule and company rules, not from a spreadsheet someone forgot to update.
• Errors in vacation accounting disappear as a whole class: date overlaps, backdated requests, vacation beyond the balance, and discrepancies between application and order are cut off at submission rather than surfacing when the period is closed.
• Decision history: each step has an author, time, and reason for rejection, so a disputed case is pulled from the log in minutes, not reconstructed from participants' memory.

The effect rests not on employee discipline but on rules in the system. HR stops manually consolidating data from chats and spreadsheets, the manager sees team workload over the schedule horizon, and payroll days match what the person sees in their own portal.

Configuration options: ready-made route, robots, external service

The company's policy determines the mode, not the other way around: in some places a standard route is enough, in others custom fields and balance calculation are needed, and in others accounting is already maintained in an external HR system. Below are three paths and their real boundaries.

The practice is this: we start with the standard route, and add customization only where the policy truly diverges from the template. This way the request remains native for the employee, and HR does not keep a second journal in parallel.

Stages of work: from policy review to system handover

Vacation requests in Bitrix24 seem like a simple setup until you start describing the route: absence type, number of approval levels, manager substitution, date transfer, recall.

An error in one condition — and the request hangs without an approver, while HR gets a discrepancy with the schedule. Therefore we start with the policy, not the setup.

1. Policy audit — we analyze who initiates, who approves and how many levels, how days are calculated, what to do if rejected at an intermediate level.
2. Route diagram — branching by type, duration, and department; we coordinate the diagram with HR before setup; edits on paper are cheaper than edits in the system.
3. Setup — request form, route, access rights, notifications and absence calendar, link with the accounting system so days are not entered twice.
4. Testing on real scenarios — vacation outside the schedule, recall, overlap with a business trip, missing approver. We look for where the request can get stuck.
5. Pilot operation — launch in one department, comparison with the previous procedure, refinement of edge conditions to zero discrepancies.
6. Training and system handover — instructions for employees and approvers, documentation, route map, roles and access.

After handover, the route is described, roles are fixed, changes are made according to a documented procedure. We reconnect when the policy itself changes or the process expands to new departments.

Request routes, access rights, and policies at handover

At handover, the customer is left not with a configured template but with a working approval contour: routes, rights, policies, and notification texts. Below is the list of artifacts we deliver together with implementation. We test each item against test scenarios rather than leaving it "in words."

• Approval routes — separate branches for annual vacation, comp time, unpaid leave, and recall from vacation; the set of approvers depends on the department and duration of absence.
• Access rights matrix — a "role → object → action" table: who submits, who approves, who sees only their department, who works with HR data and balances.
• Manager substitution rules — if the approver is absent, the request automatically goes to the deputy, and if overdue it is escalated upward: vacation requests in Bitrix24 do not hang for a week while someone is on vacation.
• Notification templates — texts of emails, chat messages, and mobile alerts: submission, approval, rejection with reason, reminder about an open request.

Plus the approval policy: response times at each step, procedure for overlapping dates within a department, rules for recall from vacation. And instructions for employees — one page: how to submit a request, where to see the remaining days, what to do if rejected or postponed.

Separately, we hand over the change log: who, when, and why changed the status — this removes most disputed situations with the HR department. We run all scenarios on a test contour together with your HR specialists before moving to the production system.

Case: absence approval in a distributed team

A company with four offices and a distributed team of more than three hundred people managed vacations in correspondence: email, messenger, oral agreements. The HR service manually consolidated day balances between locations.

Before implementation, the average approval time remained at four working days: every eighth request was lost in correspondence and surfaced only after the vacation had started.

Managers did not see overlaps in critical roles — a shift could end up with two people of the same competency.

We built a single route on Bitrix24 business processes: the request is created from the employee card, and the system fills in the absence type, dates, and remaining days.

The route branches — short comp time is approved by the immediate manager, a long vacation goes to the direction manager, and when dates overlap, the deputy from the org structure is connected.

Rights were divided by department: a manager sees only their branch, the HR service sees the entire flow and absence calendar. The approver responds to the notification directly from the work chat.

After launch, most requests are approved within one working day, and going on vacation without processing almost disappeared. The HR service stopped reconciling balances manually, and the route can be replicated to a new location in a couple of days.

What to do if some approvals are already happening in spreadsheets and email?

Implementation most often catches the process midway: some requests are already approved by email, some are hanging in a spreadsheet, and for someone the days are marked in the schedule.

Therefore we migrate not everyone at once, but from a cutoff date: requests started earlier are completed according to the previous rules, while everything new is created already in Bitrix24.

We transfer data outside the system in the volume needed for calculation — remaining days for each employee as of the cutoff date, statuses of approved requests, approver roles.

We do not pour email threads over verbatim: we preserve the decision and date; this is enough both for audit and for a correct balance.

We do not recreate active requests. If the route is more than halfway completed, it is cheaper to finish it in the spreadsheet than to restore the approver chain; if one step remains, we transfer it to the system with the status "approved" and the attached decision. The criterion is simple: how many manual actions the transfer will save versus finishing in place.

Directories — vacation schedule, managers and deputies, department limits — are synchronized before launch and checked on a trial request: whether balances were pulled in, whether the route went to the person who actually approves, whether notifications were duplicated.

When the last external request is closed, we disable the old channel: switch the spreadsheet to read-only mode and remove the auto-reply for the request address. The process does not stop for a single day — only the entry point changes.

Technical concerns: rights, notifications, integrations

Technical questions at the route diagram approval stage concern not the route itself but edge situations: who signs instead of the manager, how to approve from a phone, and what to do when a company has several schedules.

We sort them out before setup begins — this way the scheme immediately fits real roles and calendars instead of being redone after launch.

Can approvals be done from a phone?

The mobile app provides the same actions as the web version: approve, reject, return for revision with a comment. The notification opens the request card immediately — a decision takes a couple of taps and does not wait until the manager returns to a computer.

How are comp time and overtime accounted for?

Comp time is a separate request type with its own route and a link to previously worked time. The hour balance is visible in the card: the employee checks the remainder, the manager checks the basis for approval.

If overtime accounting is already maintained in the accounting system, the request type is linked to it and double entry does not occur.

What if the company has several schedules?

The schedule is pulled by employee from the accounting system, so vacation in a shift mode is calculated by their norm, not by the general five-day week. Overlap of requests within a department is checked at submission — the system shows how many shifts are available.

Let's discuss your approval scheme and move it into the system

To come back with a task estimate and work plan, we need a minimum of source data about how your vacations are currently organized. Discussing the policy takes one meeting — after that we describe the approval routes and show how each of them will fit into the system.

• Absence types: annual vacation, comp time, unpaid days, donor days — what we consider absence and how.
• Approval routes: who approves at each step, where a parallel response is needed, who is connected as a substitute.
• Roles and rights: manager, HR, payroll specialist, director — who sees requests for their department and who sees all.
• Balance accounting: where available days come from and how the vacation schedule, production calendar, and carryovers are linked.
• Employee entry point: a card in the system, mobile app, or chat — the set of notifications depends on it.
• Exchange with accounting systems: where the approved request goes and what returns to the employee card.
• Examples: 10-20 real requests from the previous period, including rejected and manually approved ones.

If some data is missing — no problem, we will restore it from your emails and spreadsheets. Describe the task in free form: we will come back with a task estimate, timelines, and a stage-by-stage work plan.