A single architect working alone in a Revit file never needs to think about worksharing. The moment a second person opens that same project, everything changes: two people editing the same wall at the same time is not a hypothetical, it is Tuesday. Worksharing is the set of features that makes multiple people editing one model at once possible without anyone overwriting anyone else's work.

This is the practical, tool-level half of the coordination story our "What Is BIM?" guide tells at the methodology level - a Common Data Environment describes the idea of a shared, always-current model; worksharing is how Revit specifically implements it.

Central Model and Local Models

A workshared Revit project has exactly one central model - the master file, held in one controlled location (a network drive, or Revit Cloud Worksharing on Autodesk Construction Cloud / Forma), containing the definitive, current state of every worksets, every element, and the full revision history. Nobody edits the central model directly.

Instead, each team member works from a local model: a copy of the central model saved onto their own machine. All actual editing happens in the local file. Periodically, each person runs Synchronize with Central (SWC), which pushes their changes up to the central model and pulls down everyone else's changes since their last sync. Skip syncing for too long, and your local model drifts further from the current shared state, making eventual conflicts more likely and the sync itself slower.

Worksets: Dividing the Model Into Editable Zones

A workset is a named subset of a project's elements that can be borrowed and edited as a group. Worksets exist to keep editing boundaries clear: a discipline-specific workset for structural elements, another for interior partitions, a shared workset for elements many teams touch. The practical best practice is narrower than it sounds: use worksets for coarse organizational boundaries, but rely on element borrowing, not whole-workset checkout, for day-to-day editing - checking out an entire workset blocks everyone else from touching anything in it, while borrowing only locks the specific elements you are actually changing.

How Borrowing and Editing Requests Actually Work

Revit's element-level locking is automatic and mostly invisible until it isn't. When you edit an element nobody else is touching, you silently become its "borrower" and can make changes freely. When you try to edit an element someone else is already editing, Revit blocks the change and offers to place an editing request instead - a notification to the current owner, visible in the Editing Requests dialog, that someone else needs that element released.

When you synchronize with central, borrowed elements are relinquished by default, freeing them up for the next person - useful, but worth knowing, because it means an element you were mid-edit on can become available to a teammate the moment you sync, not just when you explicitly release it. If you are not finished with an element and syncing would be premature, the Synchronize with Central dialog lets you keep your borrowed elements instead of relinquishing them automatically.

Linked Models: The Other Half of Coordination

Worksets solve collaboration within one discipline's model. Coordination between disciplines - architectural, structural, MEP - runs through linked models instead: each discipline keeps its own separate Revit file, and every other discipline links the others in as reference geometry, visible but not directly editable. This is deliberate separation of concerns: an MEP team should never be able to accidentally move a structural column, only see where it is.

Linked models are also what makes clash detection possible in the first place (typically federated further in Navisworks or a similar coordination tool) - each discipline's model stays authoritative for its own content, while the combined, linked view is where conflicts between disciplines actually get caught.

Cloud Worksharing vs. On-Premises

Traditional worksharing keeps the central model on a local network server, which works well for a single office but breaks down the moment a project spans multiple offices or includes outside consultants over a slow connection. Revit Cloud Worksharing, hosted on Autodesk Construction Cloud / Forma, replaces the network-drive central model with a cloud-hosted one, letting distributed teams collaborate in real time regardless of physical location - at the cost of everyone needing a reliable internet connection and matching cloud project access.

One version-compatibility rule catches teams by surprise: a cloud-hosted project locks to the Revit version used the first time it was published to the cloud, and every team member must stay on that same version for the life of the project - there is no "upgrade the cloud model" the way you can upgrade a local file.

Keeping a Workshared Project Healthy

A handful of habits separate a smooth-running workshared model from one that generates constant sync conflicts and frustration:

  1. Sync early, sync often. A local model that goes days without syncing accumulates both a larger set of changes to reconcile and a higher chance of colliding with someone else's edits to the same elements.
  2. Restrict write access to the central model's location. The central file should only ever be touched through Revit's own Synchronize with Central process - direct edits or accidental deletion of the central file itself can corrupt the project for everyone.
  3. Assign worksets by real editing boundaries, not arbitrarily. Worksets that map to how the team actually divides work (by discipline, by building zone) prevent unnecessary borrowing conflicts; worksets that don't map to anything real just add bookkeeping overhead.
  4. Match Revit versions across the whole team, especially on cloud-hosted projects where this is enforced rather than optional.
  5. Compact the central model periodically. Over time, a central model's file size grows from accumulated revision history; an occasional compact keeps performance from degrading.

Where This Fits

Worksharing is not a beginner topic, and that is by design - it only becomes relevant once you are working inside a team on a live project, which is exactly the point where most self-taught learners have the least guidance. Understanding it before you hit your first real multi-person project turns a frustrating first week of unexplained "someone else is editing this" errors into a non-event.

If you want hands-on practice with real team workflows instead of learning worksharing the hard way on your first job, that is exactly what our courses are built to teach.