Setting up Bitrix24 conferencing: where quality breaks
Bitrix24 conferencing setup is usually considered complete while there are five people in a meeting.
At the tenth participant, video call quality drops not as a failure but as degradation: audio lags behind the picture, the image falls apart on movement, and someone goes silent mid-sentence. Formally, the service works; in practice, the meeting has to be rescheduled.
Connection drops during a meeting are rarely related to the portal itself. More often, the media stream goes directly between participants and hits guest Wi-Fi without prioritization, the corporate firewall, or an overloaded office outbound channel.
One narrow segment is enough — and it falls apart for everyone, including those whose connection is fine.
A separate issue is external participants without an account. An invitation by link hits the extranet boundaries: a contractor or client cannot get inside, and the meeting is moved to a third-party service, losing permissions, history, and context.
Meeting recording also isn't enabled with a single checkbox. You need to decide where the file is stored, who owns it, how long it lives, who has access, and how participants' consent is recorded.
Alongside that are moderation rights: without them, anyone who joins can mute microphones and turn off cameras.
All four failures are closed by configuration, networking, and policy, not by replacing the portal. Let's look at exactly how.
How team work changes after moving meetings to the portal
When an event is created in the portal calendar, the meeting room and invitation link appear along with it. A reminder goes to the app and email ten minutes before the start; entry is possible from a browser, desktop app, and mobile app — without installing separate programs.
In practice, gathering participants is reduced from five to seven minutes of waiting to forty to sixty seconds.
The class of failures called “the call didn’t happen” goes away separately. The room lives on the Bitrix24 side, not on the organizer’s machine: if the host loses internet or the laptop battery dies, the meeting continues, and they rejoin it without creating a new one.
For critical discussions, we set up a backup path via a phone line — if the primary channel is unavailable, a participant dials in and joins the same meeting.
Recovery after a failure becomes predictable: the disconnect is recorded, the client reconnects to the room with the same ID, and recording continues on the service side.
One participant's track is lost for a few seconds, not the entire meeting — and there's no need to resend the link.
A unified meeting history removes manual collection of outcomes: recording, transcript, attachments, chat, and assigned tasks are stored in the event card.
Portal search surfaces agreements from months ago, and a new employee is brought into the project context simply by opening the relevant meeting.
Connection methods: portal server, external service, hybrid
The three schemes differ not by interface but by where the media stream runs and how external participants get into it. This determines channel requirements, access rules, and the set of connection limitations the portal will live with in operation.
The built-in portal server keeps meetings inside your perimeter and does not depend on third-party services, but it requires resources and accepts external guests only through a published address.
An external communication service offloads infrastructure and simplifies guest entry, but traffic goes outside the perimeter. A hybrid scheme separates these flows: internal meetings go through your own node, external ones through the service.
| Option | When it fits | Limitations |
|---|---|---|
| Built-in portal server | Meetings only inside the perimeter, strict data storage requirements | Resources are needed for the media stream, guests enter through a published address, manual scaling |
| External communication service | Many meetings with external participants, no in-house infrastructure for communication | Dependence on the channel and availability of the external platform, some settings outside the portal |
| Hybrid scheme | Mixed scenario: internal meetings plus regular external guests | Two configuration points, permissions and routing between perimeters need to be coordinated |
Before implementation, we test the scheme against the peak scenario — how many simultaneous meetings and external guests it can withstand and what happens if the channel goes down. This is what determines whether a hybrid is needed or one perimeter is enough.
Implementation procedure: from network audit to handover of policies
We start not with portal settings but with a survey: first we record what actually happens in channels and meeting rooms, and only then do we touch the configuration.
The reverse order almost always ends in rework during live meetings, after employees have already gotten used to the scenario.
- Network and meeting room audit. We measure channel quality during peak load hours, check access points, meeting room equipment, and remote employees' workstations. The output is a map of bottlenecks and a list of work to be done before launch.
- Scheme design. We determine how meetings are distributed across nodes, where recordings are stored, how external participants and telephony connect, and which scenarios are needed for mobile employees and meeting rooms with a shared screen.
- Setting up meeting access rights. Roles: who creates meetings, who invites external participants, who enables recording and who can access it. Rules are inherited from the department structure rather than issued manually to each new employee.
- Pilot group. 15–30 people from two or three departments work in real scenarios: stand-ups, screen sharing, meetings with mixed attendance. We review feedback and adjust the configuration before scaling to the entire company.
- Load testing. We launch several parallel meetings with recording, check behavior when a participant's connection drops, and see at what number of connections quality begins to degrade.
- Training and handover of policies. Instructions for employees and administrators, reviewed typical requests, escalation procedure: who is responsible for settings and who is responsible for meeting room equipment.
After handover, support remains: portal updates, communication quality monitoring, and refinement of scenarios when new meeting formats appear in the company.
Access policies, participant roles, and documentation set
Conferencing setup ends not with a “create meeting” button but with a set of artifacts that remain inside the company. Below is the package we hand over to the client: for each item it is clear who owns it, where it is stored, and what changes in it as the team grows.
- Access policies — which departments create conferences, who connects only by invitation, how one-time links are issued to external participants and after what time they stop working.
- Participant roles — organizer, moderator, speaker, observer; a rights matrix for recording, screen sharing, chat, and audio management so access is not handed out manually.
- Recording and storage rules — what is recorded by default, where the finished recording is stored, retention period, who is allowed to export it, and how automatic archive cleanup works.
- Connection scheme — links to the calendar, meeting rooms, telephony, and external platforms, as well as a list of data flows that leave the perimeter.
- Employee instructions — a one-page memo: how to connect, enable recording, share the screen, invite a guest, and what to do if the connection drops.
- Administrator policy — where to change policies, where to look at logs, how to restore access, and what to do if the recording was not saved.
We hand this over as working settings and texts in a shared repository, not as a presentation. When headcount changes or a new department is connected, the role matrix and one instruction are updated — the rest continues to work.
Case study: distributed team and regular stand-ups
A company with four offices and a distributed team of about 120 people held weekly stand-ups and project status meetings in Bitrix24.
Meetings were created manually, links were sent via chats, and some employees connected from personal accounts — recordings and minutes were not collected for everyone.
Stand-ups were regularly disrupted, and support was drowning in repetitive questions: “can’t hear,” “invitation didn’t arrive,” “can’t get in.”
What was changed and what was gained
We assembled an end-to-end scenario: permanent rooms for each regular ritual, a unified access policy by department groups, automatic meeting creation from the calendar with participant invitations and recording to a shared drive.
A separate document captured the policy — where the recording is stored, how to hand over moderation, and what to do when connecting from an external perimeter.
| Metric | Before | After |
|---|---|---|
| Share of meetings that took place | 7 out of 10 | 10 out of 10 |
| Participant connection | 3–5 minutes and colleague hints | one action from the calendar |
| Support requests about connection | more than 40 per month | occasional clarifications |
| Access to recording | by request in chat | link in the meeting card |
A month after launch, stand-up disruptions stopped, and support requests ceased to be a separate workstream. The effect came not from the calls themselves but from predictability: a meeting no longer depends on who created it and what is configured on a particular computer.
How does built-in conferencing differ from an external service?
Built-in Bitrix24 conferencing works inside the portal perimeter: control signals, media streams, and meeting recordings pass through the company's infrastructure.
An external service is a separate cloud: participants connect to it directly, while the portal remains the entry point — a link in the calendar or a button in the card.
The difference shows up in four dimensions: data control, channel load, work with external participants, and ownership model.
In terms of load, the approaches diverge in the distribution scheme itself.
The built-in option raises a node inside your network, and the outbound channel carries a stream for each remote participant — with regular meetings of 20-30 people, this is already a predictable bandwidth that is planned in advance.
An external service offloads the channel: your side sends one stream per participant, and the provider's cloud redistributes the rest.
Data control is the main divide. In the built-in scenario, recordings, transcripts, and attachments remain in your storage; retention period is set by retention policy, and access is governed by your portal rights and groups.
With an external service, recordings are stored on the provider's side, and you accept its rules: link lifetime, storage region, and export and deletion procedures.
With external participants, a cloud service is simpler: the link opens in a browser without an account, and dial-in from a phone is supported.
Built-in communication requires guest access to be enabled and permissions configured carefully; otherwise, an external partner will hit a login screen.
The ownership model is different too. The built-in option means costs for nodes, channel bandwidth, administration, and updates, but without being tied to a per-participant pricing grid.
The external one offers a predictable subscription, but with limits on duration and number of participants. In practice, a hybrid is often chosen: internal meetings in the portal perimeter, meetings with clients and contractors in an external service.
Common technical doubts before deploying communication
At the design stage, we answer the same questions: where recordings are stored, what happens if the channel degrades, whether the portal will have to be rebuilt, and how to let external participants in. Below are the answers as we give them before starting work on conferencing in Bitrix24.
Where are recordings stored, and can access to them be restricted?
Recordings are written to the portal drive, not to the organizer's device, so the meeting can be reviewed from any workstation.
Rights are inherited from the folder: a management meeting recording will not open for an ordinary employee if rights separation is configured by department.
What happens if a participant has a weak connection?
Quality adapts per connection individually: first the image quality is lowered, then video is turned off and voice remains — the meeting does not fall apart because of one weak participant. For branches with unstable networks, we enable audio priority mode in advance.
Is portal rebuilding needed, and how do guests connect?
Rebuilding is not needed: communication is deployed on the existing structure, and departments and rights are reused. Guests enter via an invitation link without an account, with a time limit and a role — they cannot accidentally be given moderator rights.
How does it work from mobile devices?
The mobile app provides the full set: joining, screen sharing, chat, and recording according to role rights.
Roles are divided into organizer, moderator, participant, and observer; an observer sees and hears but does not publish video or write in the general chat if this is closed by policy.
Let's discuss the task: we'll select a communication mode for your perimeter
To come back with an assessment and a plan rather than generalities, we need initial input: how many sites and participants, which communication scenarios are the priority — scheduled meetings, webinars with external listeners, one-time contractor connections.
It is important to know the requirements for recording and storage, as well as what is already in use: corporate portal, accounts from the directory, office telephony.
Based on the review, we send:
- A scheme for your perimeter: which communication nodes are used, how accounts and rights flow, and where recordings are stored.
- A phased implementation plan — with owners and result checkpoints at each step.
- An estimate of work: task scope, labor effort, dependencies on your infrastructure and third-party services.
- A list of integration improvements — calendar, CRM, telephony, external recording and transcription services.
- A policy and a short instruction for employees and meeting moderators.
- A pilot at one site: scenario, metrics (share of successful connections, time to meeting start), and criteria for moving to the entire perimeter.
- Support terms after launch: updates, monitoring, request procedure, and rollback in case of failure.
Let's discuss the task concretely: describe in your request the number of sites, current services, and the desired communication scenario. We'll come back with an estimate of work and an implementation plan, and then, based on your decision, we'll launch a pilot.