Revit Worksharing and Worksets: A Team Lead's Practical Guide
Worksharing lets multiple Revit users work in the same model through a central file and synchronised local copies. Worksets are user-defined collections of elements used to manage visibility and edit ownership. Set them up with the federation strategy and ISO 19650 information containers in mind, not as a free-form afterthought.
What worksharing is, in plain terms
Revit worksharing is the mechanism that allows several modellers to work in the same Revit model simultaneously. A central file holds the canonical state of the model, and each team member works in a local copy that synchronises with the central file. Worksets are containers inside the model that group elements together so visibility, ownership and edit rights can be managed at a useful granularity.
Worksets are not the same as information containers
A common mistake is to assume worksets equal the information containers described in ISO 19650. They do not. Worksets live inside one Revit model and govern intra-model collaboration. Information containers are the wider concept that includes whole models, drawings and data sets across the CDE. Decide your information container breakdown first; then design worksets that support that breakdown without duplicating it inside one file.
A workset structure that holds up
For most building projects, a small number of clearly-named worksets beats a large number of clever ones. Typical structures separate shared levels and grids, the building shell, interior elements by zone, MEP placeholders, and linked models. Names should be unambiguous to a new starter and consistent across projects so that automation, view templates and visibility settings can be reused.
Avoiding the central file failure modes
Most worksharing pain comes from a small set of recurring problems: synchronising over a poor connection without first reloading latest, keeping local files open across long periods without sync, multiple users with edit ownership of the same element, and central files placed on storage that cannot handle the load. The mitigations are well known: a documented sync etiquette, regular detach-and-archive snapshots, edit ownership audits, and central files hosted on infrastructure designed for Revit collaboration.
Aligning with ISO 19650 information management
Worksharing sits inside the wider ISO 19650 information management workflow. The CDE state model still governs whether information is in Work In Progress, Shared, Published or Archived. Worksets do not replace those states; they support the team's ability to deliver information into them. The BIM Execution Plan should name how worksets map to the project's federation and coordination cadence so the model behaviour matches the documented workflow.
Cloud worksharing changes the operational tempo
Cloud worksharing through Autodesk's collaboration services changes some of the day-to-day mechanics: the central file is hosted in the cloud, sync is more reliable across distributed teams, and collaboration extends beyond a single office network. The principles do not change. Workset design, sync etiquette, edit ownership and federation cadence all still apply; the cloud removes some friction without removing the need for governance.
Frequently asked questions
How many worksets should a project have?
Few enough that a new team member can hold them in their head; usually between five and fifteen for a building project. Large numbers of worksets often signal that the workset structure is being asked to do work that should sit at the information container level instead.
Are worksets the same as ISO 19650 information containers?
No. Worksets manage collaboration inside a single Revit model. Information containers are a wider concept that includes whole models, drawings and data sets across the CDE. Design the container breakdown first, then design worksets to support it.
Should we use cloud worksharing or a local server?
Cloud worksharing is the better default for distributed teams or projects where the federation includes external collaborators. Local server worksharing can still be appropriate for tightly co-located teams with strong infrastructure, but the operational and governance benefits of cloud worksharing usually outweigh the migration cost.
How do we recover a corrupted central file?
Recover from the most recent detach-and-archive snapshot, then re-link any local-file changes by republishing them from the team. This is why a documented snapshot cadence in the BEP matters: without it, recovery turns into hours of manual reconstruction.
Related services
Related case studies
Need help implementing this in your projects?
We build production-grade systems, not theoretical frameworks. Let's discuss your specific challenges.