Bitrix24 Drive integration: where file exchange breaks
As long as working versions of documents live on local drives and network folders, "Drive" in Bitrix24 remains a showcase for selected files.
Access to documents from a branch is handled via emails and messengers because the head office network resource is not visible from there.
Bitrix24 Drive integration in such a scheme exists only formally: file exchange between offices happens outside the system, in attachments, and with loss of context.
The first sign that the scheme is not working is that files do not sync between locations. Employees edit the same estimate offline, and the Drive keeps the version that someone managed to upload last.
Finding the needed contract turns into browsing folders and correspondence: only the person who saved it knows where the current document is.
The second layer is duplicate folders on the Drive: "Contracts", "Contracts (copy)", "Contracts_final" proliferate because each department builds its own structure.
Permissions are granted manually for each folder: when an employee is transferred or leaves, revoking access is forgotten, and a new person spends weeks asking to be granted the necessary access.
As a result, what is lost is not so much time as controllability: it is unclear where the master document is, who can see it, and which revision decisions are based on. We explain how this is addressed.
What changes after consolidating files in a single storage
While files live on personal drives, department drives, and external clouds, everyone keeps their own copy "just in case." After consolidation in Bitrix24, a single folder tree appears: a document is opened by link from a task card, email, or contract, rather than forwarded as an attachment.
Permissions become end-to-end — they are inherited from a folder down the branch. A new employee in a department gets access to the entire section in one operation; upon transfer, access is removed the same way, rather than manually reviewed across a dozen disconnected resources.
The number of copies decreases: a document keeps one current version and an edit history with author and date, instead of "final_final_2." Manual exports are replaced by automatic population of folders from cards, invoices, and templates — the employee does not waste time re-saving and moving files.
Document search time drops due to a single index: content is searched, not just the name, and there is no need to remember which storage holds the required revision.
External exchange uses a link with a limited term and view permissions, so working copies do not settle in counterparties' email.
The effect is measured before and after: how many storages there were and how many remain, what share of documents entered the single tree, how many export operations remain in the policy. The same metrics show where permissions still need to be cleaned up or remaining folders moved.
Integration modes with cloud storages
The portal Drive does not have to be filled with copies: files can remain in the cloud, while Bitrix24 stores the folder structure, access permissions, and cards, pulling content on demand.
There are several modes for connecting an external cloud, and they are chosen not by the convenience of the admin panel, but by who writes files and how often.
The difference between modes comes down to two questions: where the source of truth is and whether two-way writing is allowed. The answer determines version conflicts, the delay before a file appears on the portal, and the amount of local storage.
| Mode | When it fits | Limitations |
|---|---|---|
| Cloud as primary storage | The team already keeps files in an external service; the portal is needed for access and permissions | Delay before a file appears on the portal, conflicts during simultaneous editing |
| Hybrid file storage scheme | Some data must physically remain inside the perimeter | Without clear rules for "what goes where," search sprawls across two systems |
| One-way export to archive | The portal Drive needs to be freed from closed projects | Reverse writing is unavailable; returning a folder to work is a separate operation |
| Read-only connection | External contractors and participants who do not need to edit | Documents cannot be edited via the portal, only downloaded and uploaded again |
Folder synchronization limitations show up in large catalogs: with tens of thousands of nested files, rebuilding the tree after renaming or changing permissions takes minutes, not seconds.
It is more practical to synchronize by project folders with shallow nesting and to fix naming rules in advance — then discrepancies are visible point by point, without a full reindexing of the storage.
Work sequence: from structure audit to handover
The work sequence is built so that each step relies on a verified previous one. We do not connect exchange "at once and in full": first we analyze the existing Drive structure, otherwise duplicates and excess permissions will multiply across all sections.
-
Folder structure audit. We inventory sections, nesting depth, duplicates, volumes, and owners, separately marking public folders and documents with restricted access.
-
Mapping scheme. We determine which Drive section is linked to which storage and in which mode — one-way export or two-way exchange; we record where the master copy remains.
-
Permissions and access. We map user groups, create a separate account for the exchange service, and restrict external links to linked folders.
-
Setup on a test section. We connect exchange for one department: schedule, file size limits, behavior on version conflict. We do not touch production data yet.
-
File exchange testing. We run through creation, renaming, moving between folders, deletion and restoration from the recycle bin, version divergence, connection loss, and resumed upload. The output is a protocol with actual behavior, not expected behavior.
-
Transition to production. We migrate sections in stages, by department, with a rollback point at each step: a failure affects one area, not the entire structure.
-
Handover of policies to the client. We provide employee instructions, a file flow diagram, procedures for version divergence, and the support window.
Documentation, policies, and access matrix
A working integration is only half the result. The other half is a set of documents by which your team can independently onboard a new employee, create a section for a new department, or restore exchange after a failure without waiting for us.
We hand everything over in a format convenient for you — as pages in the corporate knowledge base or as files in shared storage.
- Access rights matrix — a table of "user group / Drive section / access level" with view, edit, and download. Rights are consolidated into groups rather than personal exceptions: a new employee gets the needed access by a single addition to a group.
- Drive folder scheme — a tree of sections with purpose, nesting depth, and permission inheritance points. Using it, a new department is connected by copying a branch, without manually rebuilding the structure.
- File handling policy — what lives on the Drive, what goes to external storage, which file types are not subject to export, who is responsible for public links and how they are revoked.
- Employee instruction — one to two pages: uploading and replacing a version, issuing a link with a limited term, behavior during simultaneous editing.
- Integration map — which accounts and service users have access to the storage, where access keys are stored, how often they are changed, and who confirms this.
- Retention and logging rules — version and recycle bin lifetimes, operation log depth, procedure for exporting logs for internal review or a security service request.
- Recovery scenarios — step-by-step actions for a stopped exchange, revoked key, or deleted folder: with the responsible person and expected time to return to operation.
- Acceptance protocol — a set of checks for each usage scenario marked "passed," signed by both parties.
The set is updated with every settings change: we make edits in the same documents so that the policy does not diverge from the actual configuration.
Case study: a unified file space for a distributed team
The client is a manufacturing holding with teams in three cities and outsourced contractors.
Files lived on local drives, in correspondence, and in personal cloud accounts: each department had its own folder structure, and the approved version of a specification or layout existed only in someone's email.
According to our measurements, an employee spent up to 15 minutes searching for the needed document, and in about a third of cases opened an outdated version.
Support received about 60 requests per month asking to grant access or find a file — this consumed almost one workday per week for each department head.
What we did
We deployed a unified file space on the Bitrix24 Drive and linked it to external storages: some folders work as a source, others receive finished materials from contractors.
Permissions were configured via inheritance by department groups; synchronization rules by file type and duplicate blocking in shared folders were added.
Archives were migrated with a script while preserving structure and modification dates, and links in tasks and feeds were updated automatically.
Before and after metrics
| Metric | Before | After |
|---|---|---|
| Document search time | up to 15 minutes | 40–60 seconds |
| Share of working duplicates | about 30% | less than 5% |
| Support requests about access | ~60 per month | 8–10 per month |
| Documents with the current version | 7 out of 10 | 10 out of 10 |
Employees stopped keeping copies "just in case": a document has one place, one current version, and a clear change history. New contractors get access to the needed folder on the day they are connected, without sending archives.
What to do if the Drive is already full and folders are duplicated?
A full Bitrix24 Drive is usually not about volume, but about the lack of separation: working files, archives of closed projects, and personal copies lie in one tree. Duplicate folders grow from the same place: a catalog is copied to make one's own version. The Drive fills faster than it is cleaned, and one day attachments in tasks stop uploading.
We start with an inventory: export by top-level catalogs with size, modification date, and owner, plus duplicate search by content rather than by name.
The output is a portal map: what is used daily, what lies as dead weight, which copies can be consolidated without losing history. This is safer than deleting by eye and then restoring attachments.
Next, we allocate an archive zone — a separate section for data on closed projects. Write permissions are removed there, read access is preserved: materials open via the previous links in tasks and comments.
Archiving of outdated data follows the rule: first we move and check access, only then we free up space in the main tree.
File migration to the cloud proceeds in stages and in the background: first the cold layer — the archive of previous periods, then heavy attachments and media.
The transfer is load-limited so as not to saturate the channel during working hours, and the catalog structure is preserved — familiar folders remain in their places.
To prevent duplicates from returning, we introduce a naming rule and one structure template per project: a folder is created once, document versions live inside it, and there are no copies "for oneself." Our engineers configure this on the portal side together with Drive and cloud storage integration.
Access rights, versions, and file conflicts
In Bitrix24, Drive permissions are inherited through the folder structure: access to a department section is available to all employees in the department, while on a subfolder with HR or contracts it is narrowed to specific people.
We grant external contractors access to one working folder for the project term — without rights to the root and with download restrictions. After the project closes, rights are removed in one operation; nothing remains "just in case."
Simultaneous editing is handled by locking: while one employee works with a document, the second receives a notification and opens a read-only copy.
If two versions were nevertheless uploaded, a new revision is created, and the previous one remains in history — file version conflicts are resolved by comparison and rollback, not by searching for copies in correspondence.
Deletion is reversible: the file goes to the recycle bin and stays there for a defined period, and the change history restores the previous revision even if it has already been edited over.
The file access log records who opened, downloaded, changed, or deleted an object — the question "where did the document go" is closed without interviewing employees.
Will an external contractor see the entire Drive structure?
No, if inheritance is disabled on their folder: the root remains closed, and access applies only to the assigned section. We restrict downloading and forwarding separately and set an access term — when it expires, rights are removed automatically.
What to do if a file was deleted from the cloud rather than from the Drive?
Restoration comes from the storage recycle bin — we configure its term and version history depth in advance so that the rollback window is predictable. If the object has already been purged from the recycle bin, the revision history on the integration side remains.
Let's discuss a file exchange scheme for your structure
To base the work timeline estimate on facts rather than assumptions, we start with a short review: who in the company shares files with whom, which catalogs already live in the Bitrix24 Drive and which are moved to an external cloud, and where copies diverge.
Describe the integration task in free form — we will compare it with your structure and come back with a storage connection plan, not general words.
All we need from you is what you already have at hand: a list of services, approximate file volumes, and how access is currently granted to departments and external contractors. Then we return with a set:
- File exchange scheme: which catalogs are synchronized, in which direction, with what permissions, and what remains read-only.
- Storage connection plan: sequence of stages, rollback points, what is migrated first, and what can be left for a second pass.
- Work timeline estimate for each stage — with a separate buffer for verification and testing on real files.
- List of risks: version conflicts during simultaneous editing, duplicates, heavy attachments, name length limitations.
- Requirements for access and service accounts — what will be needed at the start so that this is not clarified in the middle of migration.
- Acceptance procedure: which scenarios we check and by what criteria we consider the transition complete.
Tell us about your task — we will come back with an estimate and work plan. If the folder structure has not yet settled, we will review that too: we will advise what is more logical to keep in the cloud and what on site.