Nobody on a worksharing team is actually editing the same file at the same time — and that's exactly the point.
Picture five engineers "in the model together" and the natural assumption is that all five are clicking around inside one shared, live file — the way five people might co-edit one browser tab. That's not what worksharing does. The central model is a single copy stored on a server that no one opens or edits directly during normal work. Each team member instead opens their own local model — a full cached copy on their own machine — and edits that. The two copies only reconcile with each other at deliberate moments, through Synchronize with Central (SWC).
The central model is the single, authoritative copy of the project file, held on a shared server or cloud location. It is the source of truth for what the project actually contains — but by design it stays largely untouched during a working session; it mainly gets read from and written to at sync points. A local model is created once, per user, by opening the central model and letting the software save a complete working copy onto that person's own machine. From that point on, the user works entirely inside their local copy — every wall placed, every parameter changed, every view opened happens against the local file, with zero live effect on the central model or on anyone else's session. Periodically, that user runs Synchronize with Central, which does two things in one operation: it uploads that user's accumulated local changes into the central model, and it downloads everyone else's already-synced changes back down into that user's local model. Until the next sync, each person's local model quietly drifts out of date relative to everyone else's — which is normal, expected, and exactly how worksharing is supposed to behave.
When a user first joins a worksharing-enabled project, the software doesn't hand them a live connection to the central file — it hands them their own complete local model, saved onto their own machine. Every subsequent action — drawing a wall, changing a parameter, deleting a duct — happens against that local copy and nothing else. The central model on the server sits untouched in between syncs. Synchronize with Central is the only bridge between the two worlds, and it's a deliberate, user-initiated action, not a background live feed: it pushes the local user's accumulated changes up into the central model, then pulls down whatever changes other users have already pushed up since the last sync. Two people working on opposite ends of a building for hours without syncing are, for that entire stretch, working on models that have quietly diverged from each other — and that's fine, because reconciliation is designed to happen at sync points, not continuously.
False, and the difference isn't just semantic — it's the reason two whole categories of worksharing feature exist. If everyone genuinely shared one live file, two people could never both try to change the same wall, because there'd only ever be one in-progress edit happening at a time. But worksharing teams routinely have two people editing the same area, or even the same element, in their own un-synced local copies without knowing it. Element "borrowing" and worksharing requests exist specifically to police that gap: when a user edits an element, their local model quietly requests ownership (a "borrow") of it from the central model at the next sync, and if another user's un-synced local model already borrowed that same element first, the system flags the conflict or requires a worksharing request to resolve it — rather than silently overwriting one person's work. None of that machinery would be necessary if everyone were really editing one shared file in real time. It exists precisely because they aren't.
Explains why worksharing teams aren't actually editing one live shared BIM file at the same time: the central model is a single, server-stored source of truth that stays largely untouched between syncs, while each team member works in their own local model — a full cached copy on their own machine — and reconciles it with the central model only through Synchronize with Central (SWC).
The word "shared" in worksharing, combined with everyone seeing roughly the same building take shape, makes it feel like one live file is being co-edited in real time — the way multiple people might co-edit one cloud document. Worksharing doesn't behave that way. There is exactly one central model, and it is deliberately kept out of the direct editing path. What each user actually opens and edits is their own local model, a complete cached copy created the moment they first join the shared project. Nothing they do — placing a wall, changing a parameter, deleting an element — touches the central model until they explicitly choose to synchronize.
The central model is the single, authoritative copy stored on a server (or cloud-hosted service), functioning as the project's ground truth — but functioning almost entirely as a passive endpoint that local models sync against, rather than a file anyone actively works inside. A local model is a per-user, full working copy, created once and then edited independently and continuously by that one person, with zero live visibility into what anyone else is doing in their own local model. Synchronize with Central (SWC) is the single mechanism that connects the two: run deliberately by a user, it uploads that user's accumulated local changes into the central model and downloads everyone else's already-synced changes back into that user's local model, in one combined operation. Between syncs, every local model silently drifts further out of date relative to the central model and relative to every other local model — which is expected, ordinary worksharing behavior, not a malfunction.
This mechanism is exactly why element borrowing and worksharing requests exist. Because two users can be editing their own un-synced local copies of the same area — or even the same specific element — without either one knowing it, the software needs a way to detect and resolve that collision the moment it surfaces, rather than silently letting one sync overwrite the other's work. When a user edits an element, their local model requests a borrow on it; if that element is still available (not already borrowed by someone else's un-synced local edits), the borrow succeeds quietly. If it's already borrowed elsewhere, the user is prompted — sometimes via an explicit worksharing request to the current owner — instead of the conflict being silently lost. None of that governance would be necessary if everyone genuinely shared one live file with only one edit possible at a time; it exists specifically to manage the real consequence of independent local editing.
In normal day-to-day work, no — it's specifically designed to be synced against, not opened for direct editing, and platforms actively discourage or restrict directly opening the central file for routine work. It does get touched more directly during administrative operations like periodic maintenance (e.g., Revit's Compact Central File), managing worksets, or recovering from a corrupted local model, but that's distinct from the everyday modeling workflow every team member uses.
It's a combined push-and-pull: the user's local changes since their last sync are uploaded into the central model first, and then any changes other users have already synced into the central model since this user's last sync are downloaded back down into their local model. Both directions happen in the same operation, which is why a sync can occasionally involve resolving conflicts if the same element was edited on both sides.
Because reconciliation isn't automatic conflict-resolution — it's a merge that needs a definite answer for who "owns" a given edit. If both users' un-synced local models contain conflicting edits to the same element, the software can't silently decide whose change wins; that's precisely the scenario element borrowing is designed to catch early (by granting one user a borrow on the element) and, when a conflict does surface, worksharing requests are the mechanism for a user to explicitly ask the current owner to release it.
Yes. The longer a local model goes without syncing, the more it diverges from both the central model and every other user's local model, which increases the chance that two people happen to touch overlapping elements independently in that window. Frequent syncing shortens that divergence window and surfaces borrow conflicts sooner, when they're smaller and easier to resolve, rather than after hours of accumulated parallel edits.
They're separate layers of the same coordination picture. Central vs. local model governs how one discipline's single worksharing-enabled file is edited by multiple people on that discipline's own team. Federated vs. merged governs how multiple different disciplines' separate files (architectural, structural, MEP) relate to each other during coordination. A single discipline's central model can itself be one of the several files that get federated together with other disciplines' central models.
Try our BIM, CAD & Digital Design Studio
More calculators, simulators, and guides for this discipline.