Revit Worksharing: Central Models and What Corrupts Them

It is three hours before the coordination deadline when the message appears: sync to central failed, or the local model will not reopen, or Revit throws a corruption warning mid-save. Corruption in Revit worksharing almost always traces back to an interrupted sync, a damaged local model getting saved to central, or storage and network conditions that were not built for this workflow, not random software failure. For AEC firms in and around New York City running live project models with multiple users, understanding what breaks a central model and how to recover is the difference between meeting a deadline and losing days to file recovery.

Revit worksharing splits a project into one central model stored on your server or in a workshared cloud service, and individual local models for each team member. Every time you sync to central, your local edits are written back to the shared file and everyone else's changes are pulled down to your machine. That flow depends on stable storage, clean network writes, and team members relinquishing and syncing at regular intervals. When any part of that chain breaks, the central model, the local model, or both can become unusable, often right when the project needs them most.

This article is written for principals, operations managers and BIM managers at small and mid-sized architecture, engineering and construction firms working with Revit central models on active projects. You will find the real causes of model corruption, where a central model should live, how to set up worksharing across offices or remote teams, early warning signs before a file fails, and the steps to recover when a central model is damaged. This is not general file-sharing advice. It is practical guidance for the people responsible for keeping a Revit project running through construction documents and coordination.

Key Takeaways

• Central model corruption typically comes from interrupted syncs, damaged local models or storage that cannot handle frequent large file writes, not software bugs.
• A central model must sit on stable local network storage or a workshared cloud service, never on a general sync folder or consumer cloud drive.
• Detach and audit is the first recovery step when corruption appears, with rollback to a prior saved version reserved for cases where detach and audit fails.

How Revit Worksharing Actually Works

Worksharing runs on a division of labor between a single central model that holds the master copy of your project and individual local models that each team member opens on their own machine. Worksets let you carve up ownership of elements so two people don't edit the same wall at the same time, and the save to central process is what pushes your changes back to the master and pulls in everyone else's work.

Central Models, Local Models and the Role of Each

The central model is the authoritative copy of your project. It lives on a server or inside a cloud service built for this workload, and it stores ownership information for every workset and element. No one opens the central model directly.

Instead, you create a local model on your own machine by opening the central model through Revit's worksharing workflow. The local model is a working copy tied to you. You make your edits in the local model, and when you save to central, Revit pushes your changes to the central model and pulls down everyone else's updates.

Each team member has their own local model. That separation is what makes simultaneous editing possible. You work in your local, your colleague works in theirs, and the central model coordinates who owns what.

If your local model becomes corrupted or bloated, you delete it and create a fresh one from central. The local model is disposable. The central model is not.

Worksets and Why They Exist

A workset is a collection of elements grouped together for ownership purposes. When you borrow a workset or an individual element, you gain the right to edit it, and no one else can change it until you relinquish ownership or sync back to central.

Worksets prevent two people from editing the same wall, floor or family at the same time. Without them, the second person's save would overwrite the first person's work.

Common workset strategies include:

• By discipline: architecture, structure, MEP
• By building system: shell, interior, site
• By level or wing: floors one through five, tower versus podium

The right number depends on project size and how many people touch the model at once. A small project with three users may need only a handful. A large multi-discipline tower may need dozens to keep team members from stepping on each other.

You also have the option to borrow individual elements without taking the entire workset. That gives finer control when several people work in the same area.

The Save to Central Process Step by Step

When you click save to central, Revit performs a specific sequence. First, it saves your local model. Then it checks for changes other people made to the central model since your last sync.

If someone edited an element you also changed, Revit flags the conflict and asks you to resolve it. Once conflicts are resolved, Revit writes your changes to the central model on the server or cloud service.

After the write completes, Revit downloads the latest version of the central model back to your local. That refresh includes every change your teammates synced while you were working. The process finishes when Revit updates your local model with the new data.

Relinquish means giving up ownership of worksets or elements after you sync. You can choose to relinquish borrowed items when you save to central, or you can hold onto them if you plan to keep working in that area. Holding worksets for long stretches without syncing raises corruption risk, because your local model drifts further from central and conflicts pile up.

An interrupted sync is one of the most common causes of central model corruption. If your network drops mid-save or your machine crashes during the write, the central model can end up with incomplete data. That's why stable network storage or a workshared cloud service matters more than raw speed.

What Corrupts a Revit Central Model

Revit central model corruption usually stems from a sync process that fails halfway through, conflicts between local models over who controls specific elements, or technical strain from file size combined with hours-long editing sessions. These aren't abstract risks: they're the mechanical breakdowns that turn a productive worksharing setup into an emergency recovery.

Network Interruptions During Sync

When you save to central, Revit transfers a large block of data from your local model back to the central file. If your network connection drops or stutters during that transfer, the central model receives incomplete information. The file's internal structure becomes inconsistent, and you'll often see a "Central Model is Corrupt" message the next time someone tries to sync.

A sync interruption can happen when someone closes their laptop lid mid-save, when a wireless connection wobbles, or when a network switch reboots during the upload. File-based worksharing is especially vulnerable because it depends on continuous write access to the server hosting the central model. A connection that's stable enough for email can still trip up a 500 MB Revit sync.

The Worksharing Monitor used to track real-time sync activity and alert you to concurrent saves or connection problems, but Autodesk removed it from cloud-based environments in recent versions. Without that visibility, you won't know a sync has failed until Revit throws an error or the central model refuses further updates.

Multiple Users Fighting Over the Same Elements

Every element in a Revit model has an owner. When two people edit the same wall or view at the same time, their local models build conflicting ownership records. When both users sync, the central model tries to reconcile those records and can end up with corrupted element data or broken workset assignments.

Element ownership conflict is more common when your team uses too few worksets or when worksets are defined too broadly. If everyone borrows elements from a single "Architecture" workset, you're asking for overlapping edits. Revit will resolve some conflicts automatically, but repeated clashes leave the central model with orphaned elements or reference errors that accumulate over time.

Relinquishing elements after each sync reduces conflict, but users often keep elements borrowed across multiple sessions. That habit extends the window for overlap and raises the chance that a large Revit file picks up internal errors before anyone notices.

File Size, Complexity and Long-Running Sessions

A central model that exceeds several hundred megabytes takes longer to sync, which lengthens the exposure window for network or local-model problems. Large files also stress storage systems that aren't built for frequent massive writes. When a local model stays open for hours without syncing, it drifts farther from the central model's current state, and the next sync has to reconcile more changes at once.

Long-running sessions compound the issue. Revit's memory footprint grows as you edit, and an editing session that runs all day can destabilize your local model before you even initiate the save. If that damaged local model writes back to central, the corruption transfers.

Linked models, heavy point clouds and shared coordinates add layers of references that Revit must validate during each sync. When those references break or shift, the central model's integrity suffers. Routine audits catch some of this drift, but consistent sync discipline and storage designed for this workload are your primary defenses against a corrupted central file.

Where a Revit Central Model Should Live

The central model requires storage that can handle frequent, large, locking file writes during every save to central operation. Local network shares built for this workload and workshared cloud platforms designed specifically for Revit deliver the stability your team needs, while general-purpose sync folders introduce corruption risk.

Local Network Storage and Why Distance Matters

A central model performs best on a dedicated file server or network-attached storage appliance that sits on the same local network as your team. Each save to central writes a large file and locks the central model during the operation, so the storage system must handle simultaneous read and write requests from multiple local models without delay.

Physical distance between the server and your workstations affects performance. If your central model lives on a server in the same office, synchronization typically completes in seconds. When team members connect over VPN to a server in a different office or from home, the same operation can take minutes or fail mid-stream because the connection cannot sustain the transfer speed worksharing demands.

Network latency matters as much as bandwidth. A fast internet connection with high latency still slows every sync and raises the chance of an interrupted save, which is a common path to central model corruption.

Firms with multiple offices or remote staff working against the same central model need either a workshared cloud solution or dedicated WAN acceleration hardware. A standard VPN connection to a local server struggles with the frequency and size of worksharing saves and often leads to sync failures.

Workshared Cloud Models Through Autodesk Forma

Autodesk Forma, formerly Autodesk Forma (formerly Autodesk Construction Cloud), offers cloud worksharing through Forma Design Collaboration. This platform stores the central model in the cloud and manages the frequent file writes and locking operations that worksharing requires.

Cloud worksharing solves the distance problem. Your team can sync from anywhere without the latency and interruption risks that come with VPN connections to a local server. The platform handles versioning and tracks every save to central, which simplifies rollback if you need to recover from corruption.

Cloud worksharing integrates with other Forma tools. If your firm already uses Forma Build or Forma Data Management for document control and submittals, keeping the central model in the same platform streamlines project coordination.

The trade-off is subscription cost and reliance on internet connectivity. If your internet connection drops, your team cannot sync until service returns. Some firms keep archive copies of the central model on local storage as a backup, but the working central model stays in the cloud.

Why General Cloud Drives and Sync Folders Cause Problems

Consumer cloud drives and general sync services such as Google Drive, Dropbox, OneDrive personal sync folders, and similar platforms are not designed for the locking and large file writes that Revit central model storage requires. These services automatically sync changes in both directions, which conflicts with the one-way save to central workflow that worksharing depends on.

File locking does not work reliably on sync folders. When you save to central, Revit locks the central model briefly to write your changes. A sync service may interpret the lock incorrectly or attempt to sync a partial file mid-write, which corrupts the central model.

Version conflicts are common when multiple team members sync at the same time through a general sync folder. The platform may create duplicate copies or overwrite changes, both of which break worksharing ownership tracking. You lose the ability to see who owns which workset and which elements are editable.

If you need central model storage outside your local network, use a workshared cloud platform built for this workload rather than adapting a general sync folder. The corruption risk and lost work from a failed sync on the wrong storage far outweigh the convenience.

Revit Worksharing Over a Wide Area Network

When a second office or remote team member needs to access your central model, the frequency and size of worksharing saves quickly expose the limits of a standard VPN connection. WAN acceleration systems and cloud worksharing both address these limits, but they do so in fundamentally different ways.

Why a Standard VPN Connection Struggles With Central Models

A VPN tunnel routes traffic between your remote workstation and your local network server, but it does not change the fact that every save to central transmits the full set of changes across that connection. A Revit local model held by a remote user syncs with the central model several times each day, and each sync moves changes in both directions.

The size of these transactions depends on what has changed since the last sync. Worksets that include large families, linked models or detail-heavy geometry push more data through the connection. A standard VPN connection carries this traffic at whatever upload and download speed the remote user's internet service provides, and that speed is often far below what the same user would see on the office LAN.

Revit expects the central model to respond quickly. When the connection is slow, the sync operation takes longer, the Revit interface freezes while waiting, and the chance of an interruption rises. A dropped connection during a save to central can leave the central model in an inconsistent state, raising corruption risk. Remote team members working over VPN also report longer wait times when opening a local model or borrowing worksets, because those operations require round trips to the central model as well.

Acceleration and Caching Options for Remote Offices

A WAN acceleration setup places a caching appliance or Revit Server Accelerator at the remote office. This device keeps a local copy of the central model and serves it to users at LAN speeds. When a remote user syncs, the accelerator writes the changes to its cache immediately and then forwards them to the central model over the WAN connection in the background.

This approach separates the user's experience from the WAN latency. The remote team member syncs as quickly as someone in the main office, because the transaction completes against the local cache. The accelerator handles the slower connection to the central model without blocking the user.

Revit Server was Autodesk's on-premises solution for this workflow and supported multiple accelerators across offices. It has been deprecated in favor of cloud-based options, but many firms still run it. Firms planning a new WAN acceleration deployment now typically consider third-party appliances or move to cloud worksharing instead.

What Changes When a Second Office or a Remote Team Member Joins

Cloud worksharing moves the central model off your local server and into a service designed for this workflow. Autodesk Forma, formerly Forma, provides Forma Design Collaboration for this purpose. Each user connects to the cloud-hosted central model over the internet, and the service handles caching and synchronization.

The central model no longer sits on your network storage. Your backup and storage planning shifts to the cloud service's retention policies. Remote users and consultants gain access through the same service without requiring a VPN to your office network or an accelerator at their location.

The trade-off is that your entire project team now depends on internet connectivity and the cloud service's availability. Consultant access to the central model becomes simpler, because you grant access through the cloud platform rather than opening a path through your firewall. Firms with distributed teams or frequent outside collaboration find this arrangement more flexible than maintaining dedicated WAN acceleration hardware at each office.

When a Single Central Model No Longer Fits the Project

Large or complex projects eventually reach a point where adding more elements to a single central model creates more problems than worksharing alone can solve. Performance degrades, coordination becomes harder to track, and the risk of one sync problem affecting the entire team grows with every discipline added to the file.

Splitting a Model by Phase, Building or Discipline

You can divide a project into separate central models when the physical scope, schedule or team structure makes it practical to do so. A phased renovation can split into existing conditions, demolition and new construction models. A campus or multi-building project can place each building in its own file. Multi-discipline work often separates architectural, structural and MEP models so that each team works in its own central file without waiting on workset locks from other trades.

Each split model runs its own worksharing cycle with independent local files, worksets and sync schedules. You link the models together using linked Revit models so that the full design remains visible and coordinated. This federated model approach keeps individual file sizes smaller, reduces the number of users competing for worksets in any one file, and isolates a sync or corruption problem to a single model rather than halting the entire team.

The tradeoff is more complexity in managing shared coordinates, linked file paths and synchronization timing across models. One discipline's changes only appear in another discipline's view after the first team syncs to central, the second team reloads the link, and both models remain properly aligned.

Linking Models Instead of Growing One File Indefinitely

Letting a single central model grow without limit eventually produces a file that takes minutes to open, freezes during syncs, and becomes difficult to audit or roll back when corruption appears. Linking models before that point gives you smaller, faster files that remain stable under the load of frequent saves to central.

Linked models also let different teams work on separate schedules. The architect can push design changes without waiting for the structural engineer to finish a calculation run, and the MEP team can reload the architectural link when ready rather than syncing into a live central model at the same moment.

You manage linked models through the Manage Links dialog, where you set each link to overlay or attach, control visibility in worksets, and reload updated versions. Proper link hygiene requires each team to sync regularly and communicate when a major change affects shared coordinates or grid placement, since a misaligned link creates coordination errors that worksharing alone cannot catch.

Signs a Model Has Outgrown Its Current Structure

File size growth beyond several hundred megabytes often signals that a model holds more content than one central file should carry. Open and sync times stretch into minutes, warnings pile up, and your team spends more time waiting than modeling.

Workset contention increases when too many users need the same elements at the same time. If multiple disciplines constantly request edits from one another or if borrowing worksets becomes a bottleneck, the project likely needs discipline-specific models linked together rather than everyone working in one file.

Performance problems during routine tasks point to an overloaded model. Slow view switches, lagging section cuts, and long waits for the Synchronize with Central dialog all suggest that the central model holds more geometry, detail or linked content than Revit can handle efficiently in a single file. Splitting the model and converting some content into linked files usually restores acceptable speed.

Early Warning Signs Before a Model Fails

A workshared project rarely fails without warning. Teams that catch sync errors early, monitor journal file growth, and treat audit workflows as scheduled maintenance instead of panic responses keep their central models stable through delivery.

Sync Errors and Dialog Box Warnings Worth Taking Seriously

Recurring sync errors signal that your central model or local copy is beginning to degrade. When Revit displays a dialog during Synchronize with Central that warns about elements owned by another user, missing worksets, or elements that cannot be saved, treat those warnings as early indicators rather than noise.

Worksharing Monitor warnings deserve the same attention. Messages about slow network connections, delays accessing the central file, or editing requests that cannot be delivered point to infrastructure stress or coordination breakdowns that will compound if ignored. BIM managers should review Worksharing Monitor notices daily on active projects.

Document every sync warning in a shared log. Note the user, timestamp, and specific warning text. Patterns reveal whether the issue stems from one local model, a particular workset, or the central model itself. If the same user triggers warnings repeatedly, their local file may be damaged and should be discarded in favor of a fresh copy created from central.

Growing Journal Files and Unusual Model Behavior

Revit writes every command and operation to a journal file during each session. A healthy journal file grows predictably, but a file that balloons to tens of megabytes in a single day indicates that Revit is encountering repeated errors, retrying operations, or logging excessive undo chains. Check the journal file size at the end of each workday.

Unusual model behavior accompanies journal bloat. Views take longer to open, elements disappear and reappear without explanation, or the model crashes during routine tasks like placing a door or tagging a wall. These symptoms mean corruption is already present in the central model or a local copy that has synced its damage back.

You may also notice that certain worksets become slow to borrow or that relinquishing elements triggers long pauses. When borrowing and relinquishing lag, the central model's internal registry of element ownership is fragmenting. Run a detach and audit before the issue spreads.

When Audit and Compact Become Routine Maintenance

Audit and compact should be scheduled maintenance, not emergency repairs. Plan to audit your central model weekly on large projects and monthly on smaller ones. Auditing rebuilds internal data structures and removes accumulated errors before they escalate into full corruption.

To audit a central model, create a new local copy with the Detach from Central option enabled, open that file with Audit checked, then use Save As to designate it as the new central model after confirming the audit resolved warnings. Notify your team before you replace the central file so no one syncs to the old version mid-process.

Compact reduces file size by purging unused data and tightening the model database. Run compact after auditing to keep the central model lean. If you find yourself auditing more than once per week, storage performance or team sync habits need attention. Frequent audits mask the underlying issue rather than solving it.

Recovering From a Corrupted Central Model

Central model corruption stops work across the entire project team, and the recovery sequence starts with detach and audit before considering a rollback to a prior saved version. If neither approach restores the model cleanly, you may need to rebuild worksets to isolate and remove damaged elements.

Detach and Audit as the First Recovery Step

When you encounter a corruption message during sync or open, instruct every team member to close their local model immediately. Do not allow anyone to continue syncing until you resolve the issue.

Open a local model using the detach option, which breaks the link to the central model and prevents the local copy from writing data back to central. After opening detached, run the audit command by checking the audit box in the open dialog. Audit scans the model for inconsistencies and attempts to repair them.

If the audit completes without error, save the detached local as a new central model in a separate location. Do not overwrite the corrupted central file until you have verified that the new central opens cleanly and that users can create new local models from it. Notify your project team of the new central model path and confirm that everyone creates a fresh local model rather than reusing an old one.

This detach and audit sequence resolves most corruption caused by interrupted syncs or temporary network drops. It does not recover data that was lost during the corruption event, so you may still lose recent changes made since the last successful sync.

Rolling Back to a Prior Saved Version

If detach and audit does not resolve the corruption, locate the backup folder for the central model. Revit stores backup copies in a folder named after the central file with "_backup" appended, and this folder sits in the same directory as the central model.

Copy the entire backup folder to another location before opening any file inside it. Identify the most recent backup that predates the corruption by checking file timestamps. Open that backup file using detach and audit, then save it as a new central model if it opens cleanly.

Rolling back to a prior saved version means losing all work completed after that backup was created. Before you roll back, confirm with the project team what changes will be lost and whether those changes can be recreated. If the most recent backup is also corrupt, work backward through older backups until you find one that audits successfully.

This approach only works if your backup folder contains usable files. If the backup folder is empty or all backups are corrupt, you will need to recover from the most recent local model held by a team member.

Rebuilding Worksets When Recovery Is Not Clean

When a detached and audited model opens but displays missing elements, incorrect geometry or persistent warnings that point to specific worksets, you may need to rebuild the affected worksets. This process involves isolating the damaged workset, copying clean elements to a new workset, and deleting the corrupted one.

Open the recovered model and review the workset list. If warnings or errors point to a specific workset, close that workset and confirm that the rest of the model behaves normally. Create a new workset with a similar name, then use filters and selection tools to copy elements from the closed workset into the new one in small batches.

After you have transferred all recoverable elements, delete the original workset. This removes any corrupt data attached to that workset. Save the model as a new central and distribute it to your project team.

Rebuilding worksets is time-intensive and risks losing elements that cannot be cleanly copied. It should only be attempted when detach and audit or rolling back to a prior saved version does not restore full model functionality.

Worksharing Mistakes That Create Corruption Risk

Certain team habits and project setup decisions increase the likelihood that a central model will become unstable or corrupt. Leaving local models open across long gaps without syncing, skipping sync operations under deadline pressure, and setting up worksets that do not match the project size all introduce risk that compounds over time.

Leaving Local Models Open Overnight or Over a Weekend

When a team member leaves a local model open for extended periods without syncing, that local file drifts farther from the current state of the central model. Elements borrowed in that local model remain locked to that user, preventing others from editing them and creating conflicts when the delayed sync finally occurs.

The longer the gap, the more changes accumulate in both the local and central models. A sync after several days or an entire weekend attempts to reconcile hundreds of element changes at once, and any interruption during that large operation can write incomplete data back to central.

Keep local models closed when not actively working. Sync to central, relinquish all borrowed elements and worksets, then close the local file at the end of each day. This keeps elements available for the rest of the team and reduces the volume of changes that must be reconciled in a single sync.

If you must step away mid-session, sync and relinquish before you leave. This practice minimizes the window during which a network failure or system crash could damage the open local file, which in turn protects the central model from receiving corrupt data.

Skipping Scheduled Syncs to Save Time

Teams working under deadline pressure sometimes skip regular syncs to avoid the few minutes the operation takes. This decision allows local models to drift farther from central, increasing the number of element conflicts and the complexity of the next sync.

Skipped syncs also mean that other team members do not receive your changes, so they may duplicate work or design against outdated geometry. When everyone finally syncs at once near a deadline, the volume of conflicts can overwhelm the model and trigger errors that halt progress.

Set a sync cadence and stick to it. Syncing every hour or every few hours, depending on the pace of work, keeps local and central models aligned. Frequent small syncs are faster and safer than infrequent large ones.

Relinquish borrowed elements and worksets during each sync so that others can access them. This habit prevents bottlenecks where one user unknowingly locks elements that the rest of the team needs.

Too Many Worksets or Too Few for the Project Size

Creating too many worksets fragments the model into small pieces that do not correspond to how the team actually divides work. Users must toggle through a long list to find the right workset, and the overhead of managing permissions and visibility across dozens of worksets slows every session.

Too few worksets, on the other hand, force multiple users to work within the same workset, increasing the chance that they will attempt to borrow the same elements at the same time. This leads to frequent "element in use" messages and forces users to wait or work around locked elements.

Match workset count to project size and team structure. A small project with one or two disciplines may need only three to five worksets organized by major building system. A large multi-discipline project may require ten to fifteen worksets that separate structure, architecture, MEP and site work.

Organize worksets by discipline or by major building area, whichever aligns with how your team divides responsibilities. This structure reduces element conflicts and makes it clear which workset each user should activate for their portion of the work.

Review workset structure early in the project and adjust if conflicts become frequent. Adding or consolidating worksets mid-project is possible, but planning the right structure from the start reduces interruptions and corruption risk as the model grows.

Consultant and Linked Model Corruption Risks

Linked Revit models from consultants introduce files you do not control directly, and when shared coordinates shift or heavy point cloud links remain embedded in the central model, corruption risk climbs quickly. These external dependencies multiply the points of failure in a workshared environment.

Shared Coordinates Gone Wrong

Shared coordinates keep your architectural model aligned with structural, MEP, and civil files. When consultants reissue a linked model with coordinates that have drifted, elements no longer line up and your team may attempt to correct the alignment while the central model is open. This can trigger errors during the next synchronize with central, particularly if multiple users have reloaded the consultant link at different times and created conflicting coordinate data in their local models.

Coordinate drift happens when a consultant adjusts the survey point or project base point in their model without notifying the project team. The mismatch spreads when team members sync those changes into the central model. To reduce risk, establish a single shared coordinate system at project kickoff and lock both the survey point and project base point in every linked model. Require consultants to notify you before any coordinate change, and test updated links in a detached copy of your central model before distributing them to the team.

Linked Models From Structural or MEP Consultants

Structural MEP consultants deliver Revit models that your team links into the architectural central model. Each linked Revit model carries its own worksets, families, and view settings, and when a consultant's file contains corruption, that damage can propagate to your central model during the next save to central. The risk increases when consultants use a different Revit version or when they send you a local model instead of a properly detached central file.

Always request that consultants provide detached models rather than their own central or local files. Open each consultant link in isolation and run an audit before inserting it into your central model. Use the Overlay option rather than Attachment when linking, because overlay prevents nested links from loading recursively and slowing performance. Assign each consultant link to its own workset so you can unload it quickly if it introduces instability, and relinquish that workset after reloading the link so other users can update it as needed.

Point Clouds and Large Links Inside a Workshared Model

Point cloud links capture existing conditions and can range from hundreds of megabytes to several gigabytes. When a point cloud sits inside a workshared central model, every sync and every open operation must process that file, even if the majority of users never reference it. The added load increases the chance of an interrupted save to central, and if the point cloud file moves or becomes unavailable on the network, Revit will throw a missing link warning that can delay or block synchronization.

Store point clouds on accessible network storage and link them only into the local models of users who need them for coordination, rather than embedding the link in the central model. If the point cloud must appear in the central model, assign it to a dedicated workset and keep that workset unloaded by default. This keeps the file size manageable and prevents users from inadvertently syncing a corrupted or relocated point cloud path back to central.

Building a Reliable Revit Worksharing Setup for Your Firm

A stable worksharing environment depends on storage that can handle frequent large file writes, documented routines that prevent corruption before it starts, and knowing which problems belong to your BIM manager and which need IT expertise.

What Infrastructure a Stable Central Model Actually Needs

Your central model requires storage built for the way Revit worksharing actually works. Every sync from a local model writes a large chunk of data back to the central file. If your storage cannot handle these frequent large writes without interruption, you risk mid-save failures that corrupt the central model.

Local network storage options:

• Dedicated file server with RAID arrays and sufficient write performance
• Network-attached storage (NAS) designed for concurrent large file access
• Storage with regular automated backups scheduled outside peak project hours

A central model does not belong on a general sync folder or consumer cloud drive. Those services sync file changes across devices, which conflicts with Revit's own synchronization mechanism and creates version conflicts.

Cloud worksharing options:

• Autodesk Forma Design Collaboration, formerly Forma Design Collaboration (formerly BIM Collaborate Pro)
• Other cloud platforms specifically designed for Revit central model hosting

Cloud worksharing replaces the network file server with a cloud-hosted central model. This setup works well for firms with multiple offices or remote staff, since everyone accesses the same central model without needing a VPN connection to your office network. You need reliable internet access for every user and matching project permissions inside the cloud platform.

Your storage choice affects corruption risk directly. Network drops during save to central, insufficient disk space mid-write, or permission errors that prevent Revit from completing the save all introduce corruption. Storage monitoring and sufficient capacity matter as much as the hardware itself.

Standard Operating Procedures Worth Writing Down

Document the habits that prevent central model corruption and keep your team productive. A standard operating procedure does not need to be long, but it does need to cover the points where worksharing typically breaks.

Core procedures to document:

• How often to sync with central during active modeling (typically every hour or before leaving elements borrowed for long periods)
• When to relinquish worksets and elements, especially before lunch breaks or end of day
• How to close a local model properly instead of forcing Revit to quit
• Where to store local models and when to delete old ones
• What to do when the sync fails partway through

Include the audit routine in your procedure. Opening a local model with the audit option enabled before syncing catches many issues before they reach the central file. Some firms audit weekly, others before major syncs after heavy modeling sessions.

Write down your workset strategy for typical project types. Larger projects and multi-discipline models need more worksets to reduce conflicts when multiple users work simultaneously. Smaller single-discipline projects often run fine with the default worksets Revit creates when you enable worksharing.

Your procedure should also cover linked models and shared coordinates. When consultants link your architectural model into their MEP or structural model, coordinate system mismatches create problems that look like corruption but stem from incorrect project positioning. Documenting who establishes shared coordinates and how updates get communicated prevents these issues.

When to Bring in IT Support for a Worksharing Problem

Some worksharing problems belong to your BIM manager. Others need IT expertise.

Your BIM manager handles corruption recovery, workset organization, sync discipline and model cleanup. Detach and audit is the standard first step when a central model shows corruption signs. If that does not resolve the issue, rolling back to a prior backup comes next. Both tasks require someone who understands Revit file structure.

Problems that need IT support:

• Network storage performance issues affecting save times across multiple projects
• Backup failures or restore requests when the central model gets corrupted beyond recovery
• Remote access setup for team members working from home or another office
• Server capacity planning when storage fills up or write speeds drop
• Network interruptions during save to central that happen repeatedly

Firms with remote workers or multiple offices face a specific threshold. A standard VPN connection to a central model on your local server struggles with the frequency and size of worksharing saves. If your team experiences slow syncs or frequent timeouts, you need either a cloud worksharing setup or a WAN acceleration appliance. That decision and implementation require IT planning beyond what most BIM managers handle.

Bring IT support in early when the issue affects storage, networking or access rather than the Revit file itself. Waiting until a central model corrupts repeatedly wastes time your project team does not have.

Central model corruption usually stems from interrupted syncs, unstable storage or a damaged local model that writes bad data back to central. A central model needs storage designed for frequent large file writes, not a general sync folder. Recovery starts with detach and audit before rolling back to an earlier version.