Renaming a file “budget_final_v3_corrected_TRUE.xlsx” remains a common reflex among teams that share office documents. The problem does not lie in individual clumsiness: it is the lack of a technical and organizational framework that generates competing versions as soon as two people save the same file a few minutes apart. Understanding where these conflicts arise, and especially which mechanisms actually prevent them, helps reduce a source of time loss that most teams underestimate.
Critical threshold of simultaneous contributors on a shared file
Real-time co-editing tools (Google Docs, Microsoft 365, OnlyOffice) technically support dozens of editors on the same document. In practice, field feedback converges: beyond five simultaneous editors, version conflicts increase significantly, even when the platform manages automatic merging of changes.
The reason is less technical than cognitive. With six or more people in the same file, each contributor loses visibility on what others are modifying. Contradictory decisions multiply, and cognitive overload pushes some to work on a local copy, which reintroduces exactly the problem that co-editing was supposed to solve.
The solution does not lie in a more powerful tool. It lies in a governance rule: limit the number of active contributors simultaneously on the same document, even if it means sequencing interventions by time blocks or by section of the file. Choosing a GED software suitable for the size of the team facilitates this organization by centralizing access and modification rights.
File locking or co-editing: two logics that are not equal
Two main approaches coexist to avoid competing versions. They are based on opposing philosophies, and the choice between the two depends on the type of document concerned.
Locking prevents conflict upstream
File locking prohibits a second user from modifying a file until the first has released it. This is the historical method, still used in private cloud environments. Platforms like Synology Drive have recently strengthened this mechanism to prevent a user from saving a version while another modifies the same file from another workstation.
Locking works well for binary files (images, CAD files, complex Excel workbooks with macros) where automatic merging is unreliable. However, it creates queues: if a collaborator forgets to close the document, no one else can touch it.
Co-editing absorbs conflict in real-time
Real-time co-editing (Google Workspace, Microsoft 365 online) allows multiple people to type simultaneously in the same document. Each modification is continuously synchronized, and the version history keeps a regular snapshot.
Co-editing reduces conflicts on text documents and simple spreadsheets, but it does not eliminate them. As soon as a user goes offline and then reconnects, the merging engine must reconcile two divergent states. On an Excel file with cross-referenced formulas between tabs, this reconciliation sometimes fails silently.
- Collaborative text documents (meeting notes, specifications): real-time co-editing is more effective than locking.
- Files with macros, scripts, or links between tabs: locking avoids corruptions that co-editing cannot manage properly.
- Large files rarely modified (CAD templates, heavy presentations): locking with notification remains the least risky solution.
Version history: what it protects and what it does not
Version history is often presented as a universal safety net. Every modification is recorded, so you can always go back. This promise has blind spots.
The history does not indefinitely keep all versions. On SharePoint and OneDrive, the number of versions retained depends on the administrator’s configuration. By default, minor versions are purged after a certain time. On Google Drive, versions are deleted after a defined period if they have not been explicitly marked for retention.
The other limitation concerns granularity. The history records snapshots, not every keystroke. If two people modify the same cell in a spreadsheet between two snapshots, only the last save persists. The modification of the other contributor disappears without warning.
For the history to truly serve as protection, three conditions must be met:
- AutoSave must be enabled, with a backup frequency as short as possible.
- Significant versions (end of sprint, milestone validation) must be manually named to avoid automatic purging.
- A designated responsible person periodically checks that the version retention policy meets the team’s needs.
Naming conventions and access rights: the neglected organizational layer
Technology alone is not enough to eliminate version errors. The most frequent conflicts arise from a lack of shared conventions, not from software failure.
The classic case: a collaborator downloads a file from the cloud, modifies it locally, and then uploads it back to the server, overwriting the online version. No co-editing tool can prevent this scenario if access rights allow overwriting and if the team has not agreed on a simple rule: never work on a local copy when a cloud version exists.
Targeted write rights by section
On shared spreadsheets, assigning modification rights by tab or by range of cells mechanically reduces the conflict surface. Limiting write rights to the strict necessary for each contributor remains the most effective and least costly measure to implement.
Naming conventions (date prefix, version identifier) remain useful for files that cannot be co-edited in real-time. They do not replace automatic versioning, but they allow immediate identification of which file is the most recent when multiple copies coexist in a folder.
The majority of version errors do not result from a bug or a technical limitation. They stem from a gap between the tool’s capabilities and the actual habits of the team. Reducing these errors requires action on both fronts in parallel: properly configuring locking, co-editing, and version retention mechanisms, and then formalizing usage rules that each contributor knows and applies daily.
