Vacation schedule in Bitrix24: where manual approval breaks
A vacation request goes to the manager in a messenger, approval happens verbally, and HR learns about the absence after the fact. Absence tracking sprawls across three places — chat, spreadsheet, and HR system — and none of them serves as a single source of truth.
The vacation schedule stops being a document and turns into a set of agreements that everyone remembers differently.
Manual request approval does not retain state.
A request gets lost in the feed — the employee submits it again, and no one checks for overlap with an already approved period: the schedule shows two vacations on the same dates, and the department is simultaneously left without two specialists.
The manager cannot see remaining vacation days, so they approve more than the person has accrued, and the discrepancy surfaces only during calculation.
The most expensive area is reconciliation. HR administration keeps orders, timesheets, and accruals in its own system, while approved periods live in someone else's spreadsheet.
Once a month, someone manually matches two lists, and each error is discovered when it is most expensive to fix — at the end of the period.
None of these failures can be cured by persuasion and a paper policy: you need a single data source where the request, status, period overlap, and balance are checked automatically. Let's break down how this is addressed.
What changes after vacation schedule automation
First shift occurs at the input: a vacation request no longer lives in chat.
It is created in a Bitrix24 smart process and immediately carries data that used to be reconciled manually — remaining vacation days, overlap with already approved absences of colleagues, the person responsible at the current step.
A notification to the manager goes both to the card and to chat, so the request always has a recipient.
Request approval time shrinks from days to hours. The route is built in advance: department manager, for long absences — a second approver, HR connects at the final confirmation.
Each step has a response deadline, and a robot reminds about a stalled request and passes it further along the route — the process does not stop because one person is busy.
Remaining vacation days are calculated by the system, not a spreadsheet. Approved periods reduce the available limit immediately, rejected ones do not affect it, carryovers remain in the history.
Manual reconciliation before submitting a request disappears along with the class of errors "request without response": each request shows status, initiator, current approver, and date of last action.
Absence transparency changes planning: the manager sees the team calendar months ahead and distributes workload before two key people go on leave at the same time.
The result of vacation schedule automation is predictable absence windows and a clear response deadline instead of fragmented agreements.
Options for absence tracking: smart process, list, external file
The choice of absence tracking scheme in Bitrix24 is determined by three parameters: headcount, the number of approvers in the approval route, and how deeply reporting must go into analytics.
While there are up to thirty employees and one manager approves, any scheme works — divergence begins as the portal grows, when requests start overlapping by dates.
We compare three working schemes: smart process, item list, and external spreadsheet.
The first two live inside the portal and participate in the approval route; the third remains outside it and requires manual synchronization — this is the fundamental difference, not interface convenience.
| Scheme | When it fits | Limitations |
|---|---|---|
| Smart process | From 30–50 people, two or more approvers, custom fields and links to the employee directory are needed | Requires designing stages, permissions, and roles; the portal administrator performs setup |
| Item list | Up to 30 people, one approver, simple annual rotation | Narrow set of fields, weak analytics by periods, approval is connected separately |
| External spreadsheet | Tracking is done outside the portal, only the fact of approval is needed inside | No single source of data, manual transfer, file version conflicts during parallel editing |
The transition between schemes is done before the start of a new calendar period: otherwise already approved requests have to be transferred and re-approved.
Setup procedure in Bitrix24: from audit to handover
The vacation schedule breaks not at the request form but earlier — at the desynchronization of departments, permissions, and route.
Therefore we start not with settings but with a survey: how wishes are collected, who approves and on what basis, where the department summary is maintained.
- Portal audit — inventory of departments, positions, and managers, export of reference data, search for duplicates and records without an owner. We define fields for the smart process and places where data will have to be normalized.
- Approval route — chain of roles "employee → manager → HR" and points where approval runs in parallel. We separately describe return for revision and escalation if the responsible person is unavailable.
- Access rights — visibility matrix by roles, not by individuals: an employee sees their own requests, a manager sees the department, HR sees the company-wide summary. The scheme survives transfers and dismissals without manual edits.
- Data migration — vacation balances, past periods, reference data; line-by-line reconciliation with the source and a discrepancy report.
- Test environment — run of an annual cycle: submission, approval, rejection, date change, period closing. We deliberately check employee departure, manager change, and repeat request.
- Handover — instructions for HR and managers, description of the route and control points, training on real requests.
After handover, the scheme can be expanded: add absence types, change the approval order, connect reporting without rebuilding from scratch.
What remains in the portal after implementation: settings and documents
We hand over not "portal access" but a working environment: entities with filled fields, permission separation, notification scenarios, and policy texts.
The goal of the package is for the HR department to launch a new vacation schedule approval cycle without our support and make changes itself through settings.
- Smart process "Vacation Schedule" — a card with fields for dates, vacation type, status, approver, and department; configured stages from draft to approval and signed links to the employee card.
- Role-based access rights — an employee sees only their own requests, a manager sees their department, HR sees the entire environment; export and deletion of records are separately closed, and permission changes are logged.
- Notification templates — tied to stage transitions: who receives an email or chat message, what is in the subject and body, which fields are substituted automatically.
- Approval policy — manager response deadline, auto-escalation rule for silence, substitution procedure during absence, and limit on simultaneous vacations in one department.
- Automatic reminders — date-based scenarios: several days before vacation starts, for overdue approval, for undistributed days by the end of the period.
- User guide — two separate memos: for the employee (submitting a request, viewing the balance) and for the manager (approval, rejection, carryover); with analysis of common mistakes and screen screenshots.
- Balance exchange scheme — employee matching, synchronization frequency, rules for handling discrepancies, and an error log for review.
- Test run — comprehensive cycle on real department data: request, approval, rejection, reminder; we record the result as the reference for acceptance.
This composition addresses the question "what to do when the contractor leaves": settings are edited in the interface, texts are stored in the portal, not in chat.
Case: absence approval on a portal for a distributed team
A team of 40+ people across six cities and four time zones tracked absences in an Excel spreadsheet and chat. A request was written in chat, the manager confirmed verbally, HR manually reconciled dates and transferred them to a shared file.
By the end of the quarter, three versions of the spreadsheet were in circulation, and no one could say which one was current.
What was before implementation
Median absence approval time was 3–5 business days, because the request waited for a response until the manager returned to chat. Over a quarter, 8–11 disputed periods accumulated: overlaps within a department, clashes with planned releases, vacation without a substitute.
HR spent about two days a month consolidating, and restoring vacation history retroactively was almost impossible.
What was changed
On the Bitrix24 portal, we built a smart process "Absence": a card with type, dates, substitute, and links to projects. The approval route is built by org structure — manager, then HR; if there is an overlap, the owner of the adjacent department is added.
The overlap rule checks dates at input and prevents submitting a request with a clash; reminders and escalation work on a timer, and confirmed periods automatically go to the team calendar and working time tracking.
What became the result
Median approval — 6–8 hours, including time zones. The number of disputed periods dropped to 1–2 per quarter: overlaps are cut off before approval rather than surfacing at the end of the month.
Spreadsheets and chat have left the process completely; every vacation has a card with a decision history and an owner.
Approval time and the number of disputed periods are now visible on the dashboard — you can see where the route is slowing down, and the rule can be adjusted without reworking the process.
How a smart process differs from a task list and catalog
A task list, an item catalog, and a smart process are three different storage levels, not three ways to format one record. A task list is a flat record with an owner and deadline; it has no custom fields, stages, or permissions.
The item catalog in Bitrix24 is a directory of same-type records, a data source for the schedule, but it does not run the process itself. A smart process is an entity with its own fields, stages, links, and permissions for an individual item.
The vacation schedule relies on links: a request references an employee, department, period, and absence type.
In a smart process, these are reference fields to cards, so transferring an employee to another department immediately changes the summary instead of leaving text hanging in the description.
In a task list, such links live as mentions, and department-based selections are assembled manually.
| Option | When it fits | Limitations |
|---|---|---|
| Smart process | Absence tracking with approval and department summary | Requires setup of fields, stages, and access roles |
| Item catalog | Directory of employees, departments, vacation types | Does not store approval history and does not run the route |
| Task list | One-off assignments and reminders for the schedule | No stages, links, or permissions for a specific record |
Stages turn tracking into a route: draft, manager approval, HR confirmation, transfer to timesheet. Each transition records the author and time, so you can see at which stage the request got stuck.
Permissions are set per item: a manager sees and approves only their department, HR sees all requests, an employee sees their own.
Reporting is calculated by stages and fields: remaining days, number of unapproved requests, overlaps within a department — a standard selection. A task list cannot produce such a slice.
Technical doubts: permissions, integrations, data migration
Access separation is built on the department structure: rights are inherited from the department, so a manager sees their team's schedule, and HR sees the entire portal.
When an employee is transferred, visibility is recalculated automatically, and cards are not edited manually — otherwise every HR movement creates a risk that an unauthorized person will see colleagues' vacations.
For employees without portal access — warehouse, production, drivers — an external record is created: an HR specialist creates a request on their behalf, and approval follows the same route through the department manager. The schedule remains complete instead of breaking into spreadsheets by area.
How is vacation history migrated from previous spreadsheets and accounting systems?
We transfer balances and actual periods separately for each vacation type — main, additional, study — otherwise discrepancies surface during compensation calculation.
After loading, we reconcile totals by employee with the source: if a balance does not match, you can see which record it is on.
What about working time tracking and timesheets?
The approved schedule becomes the source of planned periods, and actual marks come from time tracking. Changing a date, recalling from vacation, or extending it is recorded as a separate event, so the timesheet and schedule do not diverge by month-end closing.
Are there limitations for exchange with 1C?
Exchange runs on a schedule, not at the moment a button is pressed: several minutes pass between export and data appearing.
It is not advisable to conduct HR orders and period closing simultaneously with exchange — we configure a queue and error log so that a discrepancy is visible immediately rather than surfacing during calculation.
Let's discuss the task: what we clarify before starting work
Estimating the scope of work for a vacation schedule depends not so much on headcount as on the number of approval levels and the complexity of the current tracking scheme.
Therefore, we start discussing the task with inputs: without them, any estimate is guesswork, and the implementation plan falls apart at the first approval. Below is what we clarify before starting work.
- Headcount and structure: how many employees, how many departments and branches, whether there are separate units with their own managers.
- Number of approvers: how many approval levels a request goes through, who approves and who only views, how an absent person is replaced.
- Current tracking scheme: spreadsheets, HR system, paper requests — how the schedule is maintained now and where it diverges from actual vacations.
- Grant rules: minimum continuous part, carryover procedure, reserve for unforeseen absences, limits on simultaneous absence in a department.
- Reporting requirements: which exports are needed, for whom, and how often — by balances, plan vs. actual, outstanding days.
- Integrations: whether data transfer to the HR system and payroll environment is needed, who is responsible for access and the test environment.
- Launch timelines: by which month the schedule must be generated normally, by what date an implementation plan with milestones is needed.
- Responsible persons on the customer side: who approves the smart process structure, who accepts interim results, and where to turn after launch.
Once these inputs are collected, we return with an estimate of the scope of work and a phased implementation plan — from configuring approval routes to handover to support.
Post-launch support covers policy edits, adding new departments, and changing reporting forms when HR rules change.