Revit Worksharing for Teams: Central Models, Worksets, and Sync Etiquette

Introduction

The moment a Revit project grows past one person, a single question decides whether the team ships clean models or fights the software all day: how do several people edit the same .rvt file at the same time without overwriting each other? Revit’s answer is worksharing. It is the mechanism that lets a five-person architecture team, or a fifty-person multidiscipline team, work in the same model concurrently while Revit tracks who owns what and merges everyone’s changes on a schedule.

Worksharing is also where a lot of teams quietly lose hours. A botched sync, a borrowed element nobody released, a local model someone built from the wrong copy, a central file that corrupts on a Friday afternoon. None of these are exotic. They come from a handful of habits that are easy to teach and easy to skip.

This guide walks through how worksharing actually works, how to set it up correctly from the first day of a project, how to structure worksets, the sync etiquette that keeps a team out of each other’s way, and the common causes of corruption with concrete ways to avoid each one. It is written for working BIM professionals and for architects moving into BIM who are about to share their first model.

What Worksharing Actually Does

Worksharing splits one project into two kinds of files that work together. There is a single central model that holds the authoritative version of the project, and there is a local model for each person, a personal copy on their own machine.

Nobody edits the central model directly. Each team member works in their own local copy, makes changes there, and then runs Synchronize with Central to push their work up and pull everyone else’s work down. The central model is the meeting point. Between syncs, your local copy and your colleague’s local copy drift apart, and the sync is what reconciles them.

To prevent two people editing the same wall at the same instant, Revit uses an ownership model. When you start editing an element, you become its temporary owner. Until you sync and release it, no one else can change that element. They can see it, but Revit blocks the edit and offers to send you an editing request. This element-level locking is what makes concurrent editing safe.

The practical consequence is simple. Worksharing is not magic file-merging. It is a checkout system with a shared meeting point, and the discipline of the team around that meeting point is what determines whether it runs smoothly.

Enabling Worksharing: Step by Step

Worksharing is off by default on a new project. Turning it on creates the central model. Here is the clean sequence.

1. Start from the right base file. Open the project template or the model that will become the project. Confirm it is the version everyone has agreed on. Worksharing bakes in the worksets you create, so it is worth getting the file right first.
2. Go to the Collaborate tab and click Collaborate. Revit asks whether you want to collaborate within your network or through Autodesk Construction Cloud (ACC). For a file-server based team, choose the network option. For a cloud-hosted team, choose ACC, which changes where the central lives but not the underlying worksharing logic.
3. Let Revit create the default worksets. Enabling worksharing automatically creates two user worksets (Workset1 and a shared levels and grids workset) plus the family and project standards worksets. You will reorganize these shortly.
4. Save to the central location. Save the file to the agreed network path or upload to ACC. This save establishes the central model. Its file path is now the source of truth, and everyone’s local copy will point back to it.
5. Never work in this file again directly. Once the central exists, you create a local copy and work there. Opening and editing the central file directly is one of the fastest ways to cause problems, covered later.

A note on file paths. On a network-share team, the central model’s path must be stable and identical for everyone. If half the team maps the server as drive P: and the other half opens it by UNC path, Revit can treat them as different central locations and refuse the sync. Agree on one path convention before anyone makes a local copy.

Worksets: Structuring the Model

A workset is a named collection of elements within the model. Think of worksets as functional groups: Exterior Shell, Interiors, Core, Furniture, Site, Shared Levels and Grids. When worksharing is on, every element belongs to exactly one workset.

Worksets do two jobs. First, they are the unit of ownership in older borrowing workflows and a way to take broad ownership of a region of the model. Second, and more important on large projects, they are a performance tool. You can close worksets you are not using so Revit does not load that geometry into memory. On a large model, opening only the worksets you need can cut open times and improve responsiveness dramatically.

A workable workset structure for a mid-size architectural model looks like this.

Workset	Holds	Typical use
Shared Levels and Grids	Levels, grids, scope boxes	Datums everyone depends on; lock down after setup
Exterior Shell	Facade, roof, external walls	Facade team owns it
Interiors	Partitions, doors, internal walls	Interiors team owns it
Core	Stairs, lifts, shafts	Often a single owner
Furniture and Equipment	FF&E, casework	Easy to close for performance
Site	Topography, site components	Rarely loaded by everyone
Linked Models	Structural and MEP links	Close to speed up architectural work

Keep the list short. A model with forty worksets is harder to manage than one with eight, because nobody remembers what belongs where and elements end up on the wrong workset. Name worksets by function, not by person, because team members rotate but the building does not.

One rule worth enforcing from day one: put each linked model on its own workset. That way anyone can close the structural or MEP link to speed up their session without affecting the rest of the team.

The Local Model and Why It Matters

The local model is your personal sandbox. You create it once at the start of your involvement and reuse it, syncing regularly. To create one, open Revit, browse to the central model, and Revit detects that it is a workshared central and offers to create a local copy. Accept, and Revit places the local file in your user folder by default.

The cardinal rule of worksharing is that you never work in the central model. The central is the merge point, not an editing surface. If you open and edit the central directly, you hold an exclusive lock on it, block everyone’s sync, and risk corrupting the file when you save.

A second rule: do not copy a colleague’s local model and work in it. A local model is bound to the user who created it. Sharing locals leads to ownership confusion, where Revit thinks two people are the same owner, and to syncs that fail in confusing ways. Each person makes their own local from the central.

Refresh your local periodically by creating a fresh one. Over weeks, a local model accumulates a long history and can grow large or sluggish. A common team habit is to create a new local at the start of each week, or after any major event such as a model audit. This keeps locals lean and reduces the chance of carrying forward a subtle problem.

Sync Etiquette

Synchronize with Central is the single most important action in a workshared project, and the one most often done badly. A good sync routine is mostly about timing and courtesy.

Sync often, in small increments. A team member who syncs every thirty to sixty minutes pushes small, digestible changes and pulls in everyone else’s work before it piles up. Someone who works all day and syncs once at 5 PM creates a large, risky merge and forces colleagues to wait. Frequent small syncs are faster and safer than rare large ones.

Reload Latest before a big edit. The Reload Latest command pulls down everyone’s recent changes without pushing yours. Running it before you start a significant edit means you are working against the current state of the model, not a stale one.

Relinquish what you do not need. When you sync, Revit offers to relinquish your borrowed elements and worksets. Tick the relinquish options so you release ownership of everything you are not actively editing. Elements you forget to release stay locked to you, and a colleague who needs them has to chase you down or wait for your next sync.

Add a sync comment. Revit lets you attach a short comment to each synchronize. A one-line note such as “added level 3 partitions” gives the team a readable history of who changed what.

Do not sync during another sync. On a network-share team, two people syncing at the same instant can collide on the central file. The polite convention is to glance at whether a sync is in progress, or simply to let Revit queue. ACC handles concurrency better, but the habit of not piling onto a busy central still helps.

Here is a comparison of the two main commands people confuse.

Command	Pushes your changes up	Pulls others’ changes down	When to use
Reload Latest	No	Yes	Before a big edit, to refresh your local
Synchronize with Central	Yes	Yes	Regularly, to publish your work and pull theirs

Borrowing and Editing Requests

Most teams today use element borrowing rather than taking ownership of whole worksets. When you click an element and edit it, Revit silently grants you ownership of just that element. You borrow it. You keep it until you sync and relinquish.

When you try to edit an element someone else is borrowing, Revit blocks you and offers to place an editing request. The other person gets a notification and can grant or deny it. If they have already synced and relinquished, Revit may grant your request automatically.

The etiquette here is straightforward. Respond to editing requests quickly, because a colleague is blocked until you do. Grant requests for elements you are not actively working on. And sync before you walk away from your desk for a meeting or lunch, so your borrowed elements are released and nobody is stuck waiting on you for an hour.

A frequent source of friction is one person borrowing a shared datum, such as a grid line or a level, and not releasing it. Because everyone depends on those datums, a single unreleased grid can block half the team. Lock down the Shared Levels and Grids workset once the project setup is stable, and treat any edit to it as a deliberate, announced action.

Common Causes of Central File Corruption

Central file corruption is the worry that keeps BIM managers up at night, because a corrupt central can cost a team a full day or more. The good news is that most corruption comes from a small set of avoidable causes.

Editing the central directly. Opening the central model and saving over it, rather than working in a local, is the classic cause. Always open via a local copy.

Network interruptions during sync. A dropped Wi-Fi connection or a server hiccup mid-sync can leave the central in a half-written state. Sync over a wired connection where possible, and never sync over a VPN that is known to be unstable. ACC’s cloud worksharing is more resilient here, which is one reason teams move to it.

Saving to the wrong location or with the wrong method. Copying the central file with Windows Explorer to back it up, then having someone open that copy as if it were the live central, splits the team across two files. Use Revit’s own Save As with the “make central” option if you genuinely need to relocate a central, and announce it.

Running mismatched Revit versions or stale builds. A team member on an older Revit build syncing into a central created by a newer build can introduce problems. Standardize the exact Revit version and update build across the whole team, and confirm it at project kickoff.

Skipping audits. A model that is never audited accumulates small inconsistencies that can grow into corruption. Run Audit (the checkbox in the Open dialog) on the central periodically, ideally during a quiet window, and rebuild fresh locals afterward.

If a central does become corrupt, the recovery path is usually to create a new central from the most recent healthy local model, then have everyone rebuild their locals from that new central. This is exactly why frequent syncing matters: the more recent everyone’s local, the less work is lost.

Worksharing on Large Teams

The habits above scale, but large multidiscipline teams add a few considerations.

Use closed worksets aggressively. On a model with hundreds of thousands of elements, every person should open only the worksets they need. The facade designer does not need furniture loaded; the interiors team does not need the full site topography. Closing worksets is the single biggest lever for keeping a heavy model responsive.

Establish a sync schedule for the whole team, not just individuals. Some teams stagger syncs loosely so the central is not constantly contended. Others rely on ACC, which handles concurrency well enough that explicit staggering is less necessary. Either way, agree the convention so nobody is surprised.

Designate a model owner or BIM coordinator who is responsible for the health of the central: running audits, managing worksets, refreshing the file, and being the person who relocates the central if it ever needs to move. Shared responsibility for a central file usually means no responsibility, and that is where neglect creeps in.

Common Mistakes

These come up again and again in real projects.

• Working all day, syncing once. Creates a huge, risky merge and blocks the team. Sync every thirty to sixty minutes.
• Forgetting to relinquish. Leaves elements locked to you. Tick the relinquish options on every sync.
• Copying someone’s local. Causes ownership confusion. Each person makes their own local from the central.
• Editing the central directly. A leading cause of corruption. Always work in a local.
• Too many worksets. Forty worksets nobody understands is worse than eight clear ones. Keep the list short and functional.
• Loading every workset every time. Wastes memory and slows the model. Open only what you need.
• Mismatched Revit builds. Standardize the exact version across the team.

Best Practices Checklist

A short, enforceable routine that keeps worksharing healthy:

1. Create the central once, from an agreed base file, and never edit it directly.
2. Each person makes their own local from the central. Refresh locals weekly.
3. Structure worksets by function, keep the list short, and put each link on its own workset.
4. Sync every thirty to sixty minutes, with a one-line comment, and relinquish everything you are not actively editing.
5. Reload Latest before any major edit.
6. Respond to editing requests promptly, and sync before you leave your desk.
7. Lock down Shared Levels and Grids after setup.
8. Sync over a wired connection, and audit the central periodically.
9. Standardize the exact Revit version and build across the whole team.
10. Give one person ownership of the central’s health.

Conclusion

Worksharing is not a feature you flip on and forget. It is a set of shared habits wrapped around a single central file. The software handles the mechanics of locking elements and merging changes, but the team supplies the discipline: syncing often, relinquishing what they do not need, never touching the central directly, and keeping worksets clean. Get those habits right and a large team can work in one model all day without friction. Get them wrong and you spend your week untangling locks and rebuilding from corrupt files.

If you want to build these workflows properly, from worksharing and worksets through coordination and clash detection, Archgyan’s Revit and BIM coordination courses are taught by a working BIM Coordinator and cover the exact practices firms run. Explore the courses and start sharpening the workflow your team relies on every day.