Worksharing vs Cloud Worksharing: when each makes sense in 2026

Lede: The Hidden Cost of a VPN and a Shared Drive

Picture a structural engineering firm running a mid-size mixed-use tower in three time zones. The architect of record is in London. The structural team is in Singapore. The MEP engineers spend half their week in a hotel room in Dubai reviewing shop drawings. The project kicked off eighteen months ago with what looked like a sensible setup: a beefy NAS appliance in the London office, a site-to-site VPN to Singapore, and a Windows file share that Revit treats as a local drive.

Today the London team opens the central model in two minutes. The Singapore team waits nine. The Dubai engineers — connecting over hotel Wi-Fi through two VPN hops — have given up on synchronizing from the road entirely. They work detached, manually merge on Mondays, and spend the rest of the week reconciling conflicts that never needed to happen. The BIM Manager has a recurring calendar block labelled "Central File Surgery." Nobody is happy.

This is not a story about bad decisions in 2020. It is a story that repeats itself on projects that start with a local file-sharing mindset and outgrow it without anyone noticing the inflection point. The VPN bill, the NAS maintenance contract, the IT overhead of managing SMB shares across international firewall policies, and — the cost that never appears on any invoice — the engineering hours lost to slow syncs and model conflicts, add up to a number that routinely exceeds the annual cost of Autodesk's cloud worksharing product.

That product has had several names. It launched as A360 Collaboration for Revit around 2014–2015, became BIM 360 Design in April 2018, was repackaged as BIM Collaborate Pro when Autodesk restructured its Construction Cloud offerings in 2021, and was renamed again to Forma Design Collaboration in March 2026 when Autodesk Construction Cloud itself was rebranded as Autodesk Forma. The underlying technology is the same Revit Cloud Worksharing (RCW) engine across all those names. The pricing, the ecosystem around it, and the maturity of the tooling have changed substantially.

The thesis of this article is straightforward: for any project where team members work across sites, time zones, or organizational boundaries, Forma Design Collaboration is almost always the correct answer in 2026, and the argument for staying on a local central file is narrower than most BIM Managers assume. But "almost always" is not "always," and the devil is in the specifics. A three-person architecture studio on a single LAN has no business paying for cloud worksharing licenses. A twelve-person distributed team working on a 450 MB federated model probably cannot afford not to.

This article walks through both systems at a technical level, builds a decision matrix across the axes that actually matter, catalogues the anti-patterns that cause the most expensive failures, and closes with cost analysis grounded in current Autodesk pricing data.

Part 1: How Local Worksharing Actually Works

The Central File Model

Revit's worksharing architecture has not changed in its fundamentals since Autodesk introduced it in Revit Building 7.0 in the mid-2000s. The mental model is straightforward: one central file on a file server acts as the authoritative record of the project. Every team member works in a local copy — a personal replica of the central file stored on their workstation. At intervals, each user runs Synchronize with Central (SWC), which does three things in sequence:

1. Pushes the user's local changes to the central file.
2. Pulls changes made by other users since the last sync.
3. Relinquishes any element ownership that is no longer needed.

The central file is never directly edited. It is read from and written to only through the SWC protocol. This is why Autodesk explicitly warns against opening a workshared model directly from the file server — doing so bypasses the local-copy workflow and can corrupt the central file.

Worksets: The Ownership Layer

Worksets are the organizational unit that makes multi-user editing possible. When you enable worksharing on a Revit model, the software automatically creates two default worksets — Shared Levels and Grids and Workset1 — and you typically add more to organize the model by discipline, building system, or floor zone.

Ownership of a workset, and therefore of every element it contains, can be held by a single user at a time. When you check out a workset, you hold it exclusively until your next SWC. Other users can see your work-in-progress after they click Reload Latest (which fetches the latest state from the central file without doing a full sync), but they cannot edit elements you own.

In practice, checking out entire worksets is an anti-pattern on any project with more than three or four users. The preferred workflow is element borrowing: Revit automatically requests a borrow on the specific element you click to edit, holds it for your session, and relinquishes it on the next SWC. Element borrowing gives much finer access granularity, but it has a performance cost: every borrow request requires a round-trip to the central file, which is why high-latency connections kill productivity even when sync times look acceptable.

The SWC Protocol in Detail

When a user triggers SWC, the sequence from Revit's perspective is:

1. Lock the central file. A brief exclusive lock is placed on the central file to prevent concurrent writes. No other user can run SWC during this window.
2. Write local changes. The local model's changed elements are written to the central file, along with updated ownership records.
3. Read remote changes. Changes from all other users since the previous SWC are read from the central file into the local copy.
4. Relinquish elements. Any elements or worksets marked for relinquishment have their ownership cleared.
5. Release the lock. The central file becomes available again.

The locking step is the critical constraint for multi-user performance. While one user is syncing, every other user attempting SWC is queued. On a fast LAN, a sync takes 30 seconds to a few minutes for a typical 150–300 MB model. On a high-latency WAN, the same operation can take 20–35 minutes — and during those minutes, no one else on the team can sync either.

File Server Requirements

Autodesk's requirements for a central file server are stricter than most IT teams expect:

• Local Area Network access only. The central file must be accessible via a path that behaves like a local Windows network share (SMB/CIFS). The connection must have LAN-level latency — the documented sweet spot is 1–5 ms round-trip. At latencies above roughly 20 ms, element borrowing becomes noticeably sluggish; above 50 ms, users start reporting that Revit "freezes" whenever they click on elements.
• Full SMB support. NAS devices must support Windows SMB semantics including byte-range locking. Many consumer NAS devices have incomplete SMB stacks that cause intermittent corruption. Autodesk's support documentation explicitly requires confirmation from the NAS vendor that the device "can fully support SMB and Windows networking protocols."
• No cloud sync folders. The central file path must not be inside a Dropbox, OneDrive, Box, Google Drive, or similar sync folder. These products intercept file I/O and break the byte-range locking that Revit depends on. This is a hard Autodesk requirement with no exceptions.
• Windows file system semantics. Revit is designed for the Windows NTFS file system. AFP (macOS) shares, NFS, and other non-Windows protocols are unsupported.

Why VPN Breaks Everything

The reason VPN-mediated central files cause corruption is not primarily about bandwidth — it is about latency and packet loss variability. As Autodesk's support documentation explains: "The local file and the central file exchange data constantly even if there is no sync process is running and this data traffic does not have the necessary protections to operate effectively over the variable bandwidth and latency that would be encountered on an Internet/WAN connection."

Even when a SWC is not running, Revit is continuously polling the central file for element ownership state. Every time a user clicks on an element, Revit checks whether it is available to borrow. On a LAN this check is imperceptible. Over a VPN it is 100–200 ms per check, and Revit sends dozens of these per minute during active modeling. The aggregate effect is a model that feels "sticky" or "frozen" — users wait one to two seconds after every click before the model responds.

The corruption risk is separate. When SWC is interrupted mid-write — by a VPN timeout, a packet loss event, or a dropped Wi-Fi connection — the central file can be left in an inconsistent state. Revit has some recovery logic, but it is not transactional in the database sense. Corrupted central files often require a Detach and Save As, followed by re-creating the workshared model from scratch. On large projects, this is a half-day recovery operation.

Revit Server: The Middle Path

For organizations with multiple offices that are not ready for cloud worksharing, Autodesk's Revit Server software (included with Revit licenses at no additional cost) provides a middle path. Revit Server runs on a Windows Server instance and exposes a purpose-built REST API instead of an SMB share. At each remote office, a lightweight Accelerator service caches the central model locally and handles the network communication with the host server.

The practical benefit: a Singapore user syncing to a London Revit Server host is not doing raw SMB reads from London. They are syncing with their local Singapore Accelerator, which handles the compressed delta communication with London in the background. Sync times at remote offices drop from 20–35 minutes (VPN/SMB) to something closer to 3–8 minutes for a typical model, depending on the size of the changeset and the WAN link quality.

Revit Server's limitations are real, though. It requires Windows Server infrastructure at every participating site. The host server must be maintained, patched, and backed up. Accelerator servers must be version-matched to the Revit version in use. When a Revit version upgrade happens, every server must be updated before the upgrade can proceed. And Revit Server does not eliminate the LAN requirement — it just moves the LAN to each local office. A remote worker connecting from home still hits the same VPN-over-WAN problems as without Revit Server, unless they are using Remote Desktop back into the office.

Common Bottlenecks in Local Worksharing

Based on support forum analysis and practitioner experience, the most common performance bottlenecks in file-based worksharing are:

1. Model size without housekeeping. Models that grow past 400–500 MB without regular purging of unused families, views, and detail items show disproportionate sync times. The central file grows not just with geometry but with worksharing history records. Running Compact Central Model during SWC (an option in the SWC dialog) periodically purges those records and can reduce file size by 20–40%.

2. Too many concurrent syncers. As noted above, the SWC lock means syncs are sequential. Teams with more than 5–6 active users on a single model frequently report that productive modeling time drops in the second half of the day as sync queues build up.

3. Excessive view count. Each 3D view, section, elevation, and schedule in the model adds to the data that must be synchronized. Projects that allow every team member to create personal views without discipline accumulate hundreds of views, many of which contain heavy visibility overrides. Purging unused views before a major milestone sync reduces SWC time significantly.

4. Linked model management. Total model open time is approximately the sum of opening time of each linked model. A 200 MB host model with six 80 MB discipline links has an effective footprint of 680 MB for open and reload operations. Linked models should be kept as small as possible and should not themselves contain unnecessary links.

5. Antivirus interference. Real-time antivirus scanning of the central file path is a documented cause of corruption and performance degradation. The central file directory must be excluded from real-time AV scanning on both the file server and on user workstations (for the local copy path).

# PowerShell: Central File Health Audit
# Run from a workstation with network access to the central file share.
# Outputs a report to the desktop.
 
param(
    [Parameter(Mandatory)]
    [string]$CentralFilePath,       # e.g. "\\fileserver\projects\TowerA\TowerA_Central.rvt"
    [string]$ReportPath = "$env:USERPROFILE\Desktop\CentralFileAudit_$(Get-Date -Format 'yyyyMMdd_HHmmss').txt"
)
 
$results = [System.Collections.Generic.List[string]]::new()
$results.Add("=== Central File Health Audit ===")
$results.Add("File: $CentralFilePath")
$results.Add("Run at: $(Get-Date -Format 'yyyy-MM-dd HH:mm:ss')")
$results.Add("")
 
# --- 1. File existence ---
if (-not (Test-Path $CentralFilePath)) {
    $results.Add("[FAIL] File not found at path. Check share mapping and VPN.")
    $results | Out-File $ReportPath
    Write-Warning "File not found. Report saved to $ReportPath"
    return
}
$results.Add("[PASS] File found.")
 
# --- 2. File size ---
$fileInfo  = Get-Item $CentralFilePath
$sizeMB    = [math]::Round($fileInfo.Length / 1MB, 1)
$results.Add("File size: $sizeMB MB")
if ($sizeMB -gt 500) {
    $results.Add("[WARN] File exceeds 500 MB. Consider purging unused families and compacting.")
} elseif ($sizeMB -gt 300) {
    $results.Add("[INFO] File is between 300–500 MB. Monitor growth; schedule a compact.")
} else {
    $results.Add("[PASS] File size within healthy range.")
}
 
# --- 3. Last modified time ---
$ageHours = [math]::Round(((Get-Date) - $fileInfo.LastWriteTime).TotalHours, 1)
$results.Add("Last modified: $($fileInfo.LastWriteTime.ToString('yyyy-MM-dd HH:mm')) ($ageHours hours ago)")
if ($ageHours -gt 72) {
    $results.Add("[WARN] File has not been written in $ageHours hours. Confirm active use.")
} else {
    $results.Add("[PASS] File has recent write activity.")
}
 
# --- 4. File lock test (is it currently locked / in use?) ---
try {
    $stream = [System.IO.File]::Open($CentralFilePath, 'Open', 'ReadWrite', 'None')
    $stream.Close()
    $results.Add("[PASS] File is not exclusively locked. No active SWC in progress (or file is idle).")
} catch {
    $results.Add("[INFO] File is locked. A Synchronize with Central is likely in progress, or the file is open.")
}
 
# --- 5. Network round-trip latency to file server ---
$serverHost = ($CentralFilePath -replace '^\\\\([^\\]+)\\.*','$1')
if ($serverHost -match '^\d{1,3}\.\d{1,3}') {
    $pingTarget = $serverHost
} else {
    try {
        $pingTarget = [System.Net.Dns]::GetHostAddresses($serverHost)[0].IPAddressToString
    } catch {
        $pingTarget = $null
    }
}
 
if ($pingTarget) {
    $ping       = New-Object System.Net.NetworkInformation.Ping
    $pingResult = $ping.Send($pingTarget, 200)
    $latencyMs  = $pingResult.RoundtripTime
    $results.Add("Server ping latency: $latencyMs ms")
    if ($latencyMs -lt 5) {
        $results.Add("[PASS] Latency is LAN-level (< 5 ms). Suitable for file-based worksharing.")
    } elseif ($latencyMs -lt 20) {
        $results.Add("[WARN] Latency is $latencyMs ms. Marginal for worksharing; element borrowing will be sluggish.")
    } else {
        $results.Add("[FAIL] Latency is $latencyMs ms. File-based worksharing is NOT suitable at this latency. Use Revit Server or Cloud Worksharing.")
    }
} else {
    $results.Add("[SKIP] Could not resolve server hostname for latency test.")
}
 
# --- 6. Backup file count ---
$backupDir   = Split-Path $CentralFilePath
$backupFiles = Get-ChildItem $backupDir -Filter "*.0001.rvt" -ErrorAction SilentlyContinue
$backupCount = ($backupFiles | Measure-Object).Count
$results.Add("Backup files in directory: $backupCount")
if ($backupCount -gt 20) {
    $results.Add("[WARN] High backup count may indicate frequent corruption events or a missing cleanup policy.")
}
 
# --- Summary ---
$results.Add("")
$results.Add("=== Audit Complete ===")
$results | Out-File $ReportPath -Encoding UTF8
Write-Host "Report saved to: $ReportPath"
$results | Where-Object { $_ -match '^\[(FAIL|WARN)\]' } | ForEach-Object { Write-Warning $_ }

Part 2: How Cloud Worksharing Actually Works

A Brief History: From "Project Skyscraper" to Forma Design Collaboration

Autodesk's cloud worksharing journey began publicly around 2014 with what was internally called "Project Skyscraper," a technology preview demonstrated at the AIA Convention in Chicago. The product launched commercially as A360 Collaboration for Revit (C4R) for Revit 2015–2018 users. It worked alongside the A360 platform and gave distributed teams their first credible alternative to Revit Server.

In April 2018, C4R was rebranded as BIM 360 Design and moved onto the newer BIM 360 platform. The technology was substantially the same, but the integration with BIM 360 Docs (document management) was tighter, and the Design Collaboration module — with its publish/package/share/consume workflow — was introduced. BIM 360 Design became the first version that genuinely started to displace Revit Server for multi-office firms.

In 2021, Autodesk restructured its cloud offerings under the Autodesk Construction Cloud (ACC) umbrella. BIM 360 Design became BIM Collaborate Pro, with BIM Collaborate (the non-worksharing tier) and Autodesk Docs (document management only) sitting alongside it as lower-cost options.

In March 2026, ACC was rebranded as Autodesk Forma, and BIM Collaborate Pro became Forma Design Collaboration. Autodesk was explicit that this was a name change, not a platform migration: existing licenses converted automatically, data and URLs were unchanged, and no action was required from customers.

The Three-Layer Architecture

Revit Cloud Worksharing operates across three distinct storage locations that serve different purposes:

Layer 1: The Revit Cloud Worksharing (RCW) Server This is the cloud-hosted central file equivalent. It stores the live model as a series of binary element streams, not a monolithic .rvt file. It is accessible only through Revit with a valid Forma Design Collaboration license. Nobody can browse, download, or open this layer from a web browser.

Layer 2: The Collaboration Cache (local) Each user's workstation maintains a local cache at %USERPROFILE%\AppData\Local\Autodesk\Revit\<Version>\CollaborationCache. When a user performs a Save (non-workshared) or a local save between syncs (workshared), changes go here first. This cache is what makes cloud worksharing functional over an internet connection — Revit is not doing raw file I/O against a remote server. It is working against a local cache that syncs asynchronously.

Layer 3: Forma Data Management (formerly Autodesk Docs) When a team member Publishes the model, a snapshot is transferred from the RCW server to the Forma Data Management layer. This is what other stakeholders — project managers, contractors, owners, anyone without a FDC license — see when they browse the project in a web browser. The published model is a frozen point-in-time snapshot; it does not update until someone publishes again.

Save vs. Sync vs. Publish — the Distinctions That Matter

These three operations are distinct and frequently confused:

This architecture means that cloud worksharing has two layers of "when does my colleague see my work?" — something that confuses teams migrating from local worksharing, where SWC is the only meaningful gate.

The Sync Mechanics in Detail

When a cloud worksharing user triggers Synchronize with Central, the sequence is:

1. Changes from the local CollaborationCache are compressed and uploaded to the RCW server.
2. The RCW server applies those changes and returns any changes from teammates since the user's last sync.
3. The local CollaborationCache is updated with the merged state.
4. Revit reloads the local working model from the updated cache.

The critical difference from file-based SWC is that there is no exclusive file lock. The RCW server handles concurrent writes through an element-level conflict resolution system. Two users cannot hold ownership of the same element simultaneously, so genuine write conflicts are prevented by the ownership model rather than by serialization locks. Multiple syncs can proceed concurrently without queuing.

This single architectural difference has enormous practical consequences for distributed teams. On local worksharing, sync queues are a daily frustration. On cloud worksharing, every team member can sync simultaneously without blocking anyone else.

Typical Sync Times Over the Network

Typical sync times reported by practitioners, assuming a stable broadband connection (≥ 20 Mbps, latency ≤ 50 ms):

• Small model (< 100 MB), small changeset (< 10 elements): 15–45 seconds
• Medium model (100–300 MB), typical daily changeset: 1–4 minutes
• Large model (300–500 MB), heavy session changeset: 4–10 minutes
• Very large model (> 500 MB) or first-open cold sync: 10–20+ minutes

The "first open" cold sync is the most significant outlier. When a user opens a cloud workshared model for the first time (or after clearing the CollaborationCache), Revit must download the entire model to the local cache. For a 400 MB model over a 50 Mbps connection, this takes approximately 8–12 minutes regardless of changeset size. Subsequent opens reuse the cache and are much faster.

The Design Collaboration Module: Packages and Cross-Team Workflows

Beyond the real-time co-authoring sync, Forma Design Collaboration includes a Design Collaboration module that manages how models are shared between teams on the same project. This is the feature that distinguishes FDC from a simple "Revit in the cloud" and makes it viable for multi-firm projects.

The workflow:

Set up Teams. A project administrator creates Teams within the Forma project — one per discipline or firm (e.g., Architecture, Structure, MEP, Civil). Each team has its own folder space on the RCW server and controls its own models.

Publish. When a team's model reaches a share-ready milestone, a designated team member publishes it. Publishing copies the current RCW state into the team's Work-in-Progress (WIP) folder in Forma Data Management.

Package. The team creates a Package from the published model — optionally bundling related documents, sheets, and IFC exports. A package is an immutable snapshot tied to a version number.

Share. The team shares the package to other teams. Shared packages appear in the receiving teams' "Shared" folders in the Design Collaboration module.

Consume. A receiving team explores the incoming package, uses the built-in model comparison tool to review what changed since the last shared package, and decides whether to consume it. Consuming copies the shared model into the team's "Consumed" folder, making it available as a Revit link with a stable, version-locked reference.

The Consume step is where the change review happens. The comparison viewer shows element additions, deletions, and moves between package versions — a structured, auditable handoff that replaces the informal "I'll send you the latest Revit file" workflow that characterises many traditional projects.

Desktop Connector and Version Requirements

Revit Cloud Worksharing requires the Desktop Connector application running on each user's workstation. Desktop Connector manages authentication, syncs the local file cache, and provides the Windows Explorer integration for Forma Data Management.

As of Revit 2025 and 2026, Desktop Connector version 16.x or later is required. Older versions (15.8 and earlier) are incompatible with these Revit versions. This is a common source of "can't open cloud model" errors when firms upgrade Revit without updating Desktop Connector.

The Revit version lock is another critical constraint: the first model initiated to a cloud project determines the Revit version for that project. If a project is initiated in Revit 2025, all collaborators must use Revit 2025. A user opening the project from Revit 2026 will either be blocked or prompted to upgrade the model — which is a one-way, irreversible operation that locks out all 2025 users. Mid-project Revit upgrades must be coordinated across every firm on the project simultaneously.

What a Forma Design Collaboration License Actually Covers

This is a frequent source of confusion. The FDC license is required for:

• Co-authoring a cloud workshared Revit model (reading and writing via SWC)
• Publishing models to Forma Data Management
• Creating and sharing Design Collaboration packages

It is not required for:

• Viewing published models in a web browser (Forma Data Management viewer)
• Accessing project documents and drawings (Autodesk Docs, included in the AEC Collection)
• Viewing clash detection results or model coordination reports

This means a 20-person project team might have 8 active Revit users who need FDC licenses, while the remaining 12 (contractors, owners, project managers, reviewers) can participate fully using Autodesk Docs access included in their standard subscriptions.

Part 3: The Decision Matrix

The choice between local and cloud worksharing is not a single decision — it is a family of decisions that interact. The framework below evaluates seven axes independently and then synthesises them into team-topology archetypes.

Axis 2: Model Size and Complexity

Model size interacts with infrastructure choice in non-obvious ways.

Small models (< 100 MB). Cloud worksharing performs excellently. Cold-sync times are short, incremental syncs are fast, and the overhead of the CollaborationCache is minimal. Any productivity argument against cloud worksharing is weakest here.

Medium models (100–300 MB). Both approaches perform acceptably on appropriate infrastructure. LAN-based local worksharing with well-managed worksets and regular compaction handles this range comfortably. Cloud worksharing handles it well over ≥ 20 Mbps broadband. The deciding factor shifts to team topology.

Large models (300–500 MB). Local worksharing starts to show meaningful scaling constraints. At this size, cold opens take 10–20 minutes even on a fast LAN. SWC times for large changesets can reach 15–30 minutes, serializing the team queue. Model health management (purging, compaction) becomes essential discipline, not optional practice. Cloud worksharing's lack of a serializing SWC lock gives it a genuine performance advantage at this scale for teams where multiple users are working simultaneously.

Very large models (> 500 MB). At this scale, both approaches struggle, but for different reasons. Local worksharing's SWC queue becomes catastrophically long; teams often report syncs taking 45–90 minutes for a well-maintained 600 MB model. Cloud worksharing's cold-sync time (the full download to CollaborationCache) can exceed 30 minutes on a standard broadband connection. The correct mitigation for both is model decomposition: break the single large model into a federated set of smaller discipline models, typically targeting under 200 MB per authored model with the full federated set linked for coordination.

Federated model workflows. Federated models — where each discipline maintains its own Revit model and links them together for coordination — are the industry standard for large or complex projects. Cloud worksharing and the Design Collaboration module were specifically designed for this pattern. Each discipline team operates an independent RCW-hosted model, publishes to packages on a coordinated cadence, and consumes other teams' packages as Revit links. This enforces the low-trust, change-reviewed cross-team workflow described in Part 2. Local worksharing can also support federated workflows, but the cross-firm handoff requires manual file transfers or a shared file server accessible to all firms, which circles back to the multi-firm topology problem.

Axis 3: Network Reliability

Reliable LAN (< 5 ms, gigabit). Local worksharing is fully viable. Cloud worksharing works well too, as the CollaborationCache insulates Revit from the WAN, but you are paying for cloud infrastructure you do not strictly need.

Reliable broadband WAN (> 20 Mbps, < 50 ms). Cloud worksharing performs well. The CollaborationCache design was explicitly built for this profile. Element borrowing goes via the cache, not to a remote server. SWC uploads/downloads the delta, not the full model. Teams in this network category typically report cloud worksharing as "indistinguishable from local" for interactive modeling once the initial cold-sync is complete.

Unreliable or congested WAN. This is where cloud worksharing's architecture matters most. When a SWC is interrupted by a connection drop, Revit Cloud Worksharing can resume the transfer. The CollaborationCache ensures that no data is lost on the client side. The model is not corrupted by a failed sync the way a file-based central file can be. That said, teams on genuinely unreliable connections (hotel Wi-Fi, cellular, satellite internet) should adopt more frequent but smaller syncs (every 30–60 minutes) rather than large end-of-day syncs, to keep individual changeset sizes small and transfer times short.

High-latency connections (> 100 ms to the Autodesk cloud). Users in regions with poor international internet connectivity — parts of Southeast Asia, Africa, and the Middle East — occasionally report slow cloud model performance even with adequate bandwidth. Autodesk's data centres serve different regions; verifying that your project is provisioned on the nearest regional instance (US, EU, AU, or others) is important. Autodesk expanded its regional data offerings to include UK, Germany, India, Japan, and Canada as primary storage regions as of late 2025.

Axis 4: Team Size and User Count

1–5 users, single office. Local worksharing on a file server or NAS is cost-effective and technically adequate. The fixed overhead of FDC licensing (see Axis 5) may not be justified.

6–12 users, single or multi-office. The serialising SWC lock starts to matter at this user count, especially near the end of the working day when multiple users want to sync simultaneously. Cloud worksharing's parallel sync architecture is noticeably superior here. For multi-office teams in this range, the case for cloud worksharing is strong.

12+ users. Cloud worksharing is the clear choice. File-based central file with this many users on a single model produces predictable, repeated queue frustration. Note that not all 12+ users need to be co-authoring the same Revit model — model decomposition into a federated set is essential at this scale regardless of which worksharing approach is used.

External users and consultants. Each external user on local worksharing creates infrastructure and security complexity. Each external user on cloud worksharing needs only an FDC license (if they are co-authoring in Revit) or Autodesk Docs access (if they are view-only). The process of adding and removing external users is entirely self-service for the project administrator on the cloud platform.

Axis 5: Cost Analysis

This is where many BIM Managers make their decision, so the numbers deserve careful examination.

Forma Design Collaboration pricing (as of June 2026):

Based on third-party reseller pricing data (Autodesk's direct pricing requires a quote for most purchase paths):

What the AEC Collection includes: The Autodesk AEC Collection (approximately US$3,000–3,500/user/year) includes Autodesk Docs (document management and model viewing) but does NOT include Forma Design Collaboration / BIM Collaborate Pro. FDC is an additional per-user subscription on top of the AEC Collection or Revit subscription.

True cost of local worksharing:

The cost of local worksharing is frequently underestimated because most of it is indirect:

Worked example — 8-user distributed team:

Local worksharing scenario:

• NAS hardware: US$3,000 amortized at US$750/year
• IT administration: US$3,000/year
• VPN service: US$1,200/year
• Lost productivity estimate (1 hour/user/week x 50 weeks x US$75/hour fully loaded): US$30,000/year
• Total estimated: ~US$35,000/year

Cloud worksharing scenario:

• 8 × FDC licenses at ~US$870/user/year (10-pack): US$6,960/year
• Desktop Connector is free; no server hardware
• IT administration (minimal, self-service user management): US$500/year
• Total estimated: ~US$7,500/year

The productivity estimate in the local scenario is deliberately conservative. One hour per user per week on sync delays, conflict resolution, and slow element borrowing is a modest estimate for a distributed team. Many practitioners report two to three hours per week. At three hours per week, the productivity cost alone exceeds US$90,000/year for an 8-person distributed team — making the FDC licensing cost look trivial.

Axis 6: Migration Path

For projects already underway on local worksharing, migration to cloud worksharing is possible but is not a trivial operation. It must be treated as a planned project milestone, not a background infrastructure change.

What migration involves:

• Save the local central file to a standalone (non-workshared) copy
• Open the standalone copy in Revit
• Use Collaborate > Collaborate in the Cloud to initiate cloud worksharing on the Forma project
• Re-enable worksets and reassign workset structure
• Communicate the migration to all team members; everyone must open the new cloud model and create fresh local copies
• Validate that all Revit links resolve correctly in the cloud context

Migration risks:

• Version lock is set at migration time; all team members must be on the same Revit version before migration
• Worksharing history is not preserved in the cloud model (the compact-central operation clears it anyway)
• Revit link paths change; consultant teams that link your model must be notified and must update their link references

Best practice: Migrate at a project milestone, not mid-sprint. The end of a design phase (SD to DD, DD to CD) is the natural migration gate. Avoid migrating when multiple team members are in the middle of a heavy modeling session.

Axis 7: Security, Compliance, and Governance

Data residency. As of late 2025, Autodesk Forma supports primary data storage in: United States, European Union, Australia, United Kingdom, Germany, India, Japan, and Canada. This covers the data-residency requirements of most national and sub-national procurement frameworks. Organisations operating under strict data-sovereignty requirements should verify their specific jurisdiction against the current Forma regional offering list before committing.

GDPR. Autodesk has adopted Binding Corporate Rules (BCRs) for both controller and processor data transfers originating in the EU and UK, with the EU BCR approved by the Irish Data Protection Commission and the UK BCR Addendum approved by the Information Commissioner's Office in March 2025. Forma data is encrypted at rest and in transit, and project data is replicated between storage locations for disaster recovery.

Access control. Forma's project membership model gives administrators granular control over which users can access which projects, which services within a project, and at what permission level. External consultants can be given project access limited to a single project without being able to access the hub or other projects. This is operationally simpler and more auditable than managing file-server ACLs and VPN credentials.

Team Topology Archetypes

Part 4: Anti-Patterns

Anti-Pattern 1: VPN-Mediated Central File with "It Works Most of the Time"

The most expensive anti-pattern in distributed Revit work is the VPN-over-SMB central file that "mostly works." The failure mode is not catastrophic and immediate — it is slow and cumulative. Latency increases element borrowing time from imperceptible to noticeable to frustrating. SWC times grow as the model grows. Corruption events are infrequent enough that each one is attributed to bad luck rather than structural failure.

The insidious quality of this pattern is that it is self-reinforcing. Teams adapt to slow syncs by syncing less frequently, which increases changeset sizes, which makes syncs even slower and more conflict-prone. By the time the central file has its first major corruption event, the team has normalised dysfunction.

The diagnostic signal: if any team member's SWC takes more than 10 minutes on a regular basis, the infrastructure is not appropriate for the model size and team distribution. If the BIM Manager has a recurring "central file surgery" event on their calendar, the infrastructure has already failed.

The fix: Either restrict all Revit work to sessions on the office LAN (Remote Desktop for remote workers, no exceptions), deploy Revit Server with Accelerators, or migrate to cloud worksharing. There is no patch that makes VPN-based central file worksharing reliable.

Anti-Pattern 2: Switching Central File Type Mid-Project

Converting a local central file to a cloud central file mid-project is technically possible but operationally risky. The problems:

• Version lock surprise. If different team members are on different Revit sub-versions (e.g., 2025.0.1 and 2025.2), the cloud model initiates on the first version it sees. Users on newer sub-versions may be prompted to upgrade the model, which is irreversible.
• Link path chaos. All Revit links that referenced the local central file by UNC path must be re-pointed to the new cloud model paths. In a federated model with 6–8 discipline links, this is a full coordination exercise that takes hours and must be verified by every discipline team.
• Broken workset history. Worksharing history — who created which element, when — is cleared during the migration. This matters less for most teams than it does for audit-heavy projects (government, healthcare) where change attribution is required.
• Parallel working during migration. Any work done in the old local central file while the cloud migration is in progress is lost. The migration must be a hard cut; no one can work in either model during the migration window.

The fix: Plan for migration at a natural project milestone. Run a dry-run migration on a copy of the model two to three weeks before the actual cut-over to identify link resolution issues in advance.

Anti-Pattern 3: Mixing Local and Cloud Worksharing on the Same Project

Some teams, typically on multi-firm projects, end up in a situation where the architect is using cloud worksharing for their Revit model while the structural engineer is hosting a local central file. This creates two incompatible collaboration environments on the same project.

The specific failure mode: when the structural team sends their Revit model to the architect as a link, the architect's team can consume it as a package via the Design Collaboration module. But when the architect wants to share back, the structural team has no mechanism to receive a package into their local workflow — they must download the published model from Forma Data Management and manually re-link it. This manual step, repeated across every design iteration, is error-prone and creates exactly the kind of "wrong version linked" problems that the package/consume workflow is designed to prevent.

The fix: For any multi-firm project where even one participant is using FDC, every Revit-authoring participant should be on FDC. The cost of one or two additional FDC licenses for the smaller consultant firm is almost always less than the coordination overhead of operating mixed infrastructure.

Anti-Pattern 4: Ignoring Version Locking on Cloud Projects

The Revit version lock in cloud worksharing is absolute and irreversible. Once a project is locked to Revit 2025, no one can use Revit 2026 to co-author that model until the model is explicitly upgraded — which requires all participants to be ready to upgrade simultaneously.

The common failure: one firm upgrades their Revit installation to the next version (often because a new hire has the newer version, or because IT pushed an automatic update), and a team member accidentally opens the cloud model in the new version, triggering an upgrade prompt. If they confirm the upgrade without notifying all other firms, they lock the project to the new version, immediately blocking every team member still on the older version.

The fix: In the Forma project settings, disable automatic Revit version upgrades. Establish a written protocol: Revit upgrades on cloud projects require advance agreement from all co-authoring firms, a scheduled upgrade window, and verification that all participants have the new version installed before the upgrade is executed.

Anti-Pattern 5: Over-Syncing on Slow Connections

Teams migrating from local worksharing sometimes bring their sync discipline with them: sync every 30 minutes regardless. On a slow connection (hotel Wi-Fi, cellular), syncing every 30 minutes with large changesets is worse than syncing less frequently with smaller ones — the 30-minute sync takes 20 minutes to complete, leaving only 10 minutes of actual modeling time per cycle.

The correct discipline on slow connections is the opposite: work for longer, keep changesets smaller by scope (model one area at a time, relinquish elements immediately after editing), and sync when there is a natural break in the work rather than on a fixed clock.

The fix: Establish sync discipline as part of BIM execution planning. The default recommendation for cloud worksharing is to sync when you complete a logical unit of work, not on a fixed schedule. Coordinate with teammates when you know a large sync is coming.

Anti-Pattern 6: Neglecting the CollaborationCache

The CollaborationCache is the local copy of the cloud model state. When it becomes stale, corrupt, or mismatched with the server state, users see errors like "The model is not available" or "Cannot synchronize." The standard fix — clearing the CollaborationCache and forcing a fresh download — is often prescribed as a diagnostic step, but it should not be the first resort. Clearing the cache on a 400 MB model means a 15–20 minute cold-sync download before any work can resume.

Teams that routinely clear the CollaborationCache as a first-line troubleshooting step are usually masking a more fundamental problem: the Desktop Connector is out of date, the network connection is dropping during sync, or the user is opening cloud models through File > Open rather than from the Home screen.

The fix: Keep Desktop Connector current (the most common cause of cache errors). Always open cloud models from the Revit Home screen via Autodesk Projects. Treat cache clearing as a last resort, not a routine maintenance step.

Part 5: Case Studies

These are composite patterns drawn from documented practitioner experiences, not single real projects. Names and specific details are illustrative.

Case Study 1: The Architecture Firm That Outgrew Its NAS

Profile: 22-person architecture firm, three principals, single office, established Revit practice since 2012. Central file on a Synology NAS, no VPN, no remote work policy. Model sizes: 150–400 MB depending on project. Typical team: 6–8 users per project.

The problem: As the firm grew from 8 to 22 people and began running 4–5 concurrent projects, the IT overhead of managing a NAS-based central file setup grew non-linearly. Each project required its own backup schedule, its own folder permissions, and its own workset management plan. When COVID forced temporary remote work in 2020, the "we'll just use VPN" approach lasted six weeks before the first central file corruption event forced a day-long recovery. The firm was already on AEC Collection; the incremental cost for FDC was the only remaining question.

The transition: BIM Manager ran the cost model outlined in Part 3 for 8 active Revit users at the 10-pack rate. FDC licensing came to approximately US$6,960/year. The estimated IT administration saving (4 hours/week of BIM Manager time freed from server maintenance, at loaded cost) was approximately US$15,000/year. Decision was made to migrate all new projects to FDC; existing projects completed on local worksharing.

Three-project review: After three projects completed entirely on FDC, the BIM Manager reported: cold sync times on first open were the only meaningful friction point (10–15 minutes for a 350 MB model). Daily sync experience was "dramatically better" than NAS. End-of-day sync queuing was eliminated. The Design Collaboration package workflow, initially seen as unnecessary bureaucracy, turned out to improve coordination with structural and MEP consultants because every model handoff was version-tracked and auditable.

What did not go smoothly: The Revit version lock bit the firm once. An associate upgraded their personal Revit installation over a long weekend without checking with the BIM Manager. Monday morning, opening the project triggered an upgrade prompt. The associate clicked through it without reading carefully. The project was upgraded from Revit 2024 to 2025, immediately blocking two other team members who had not yet upgraded. Emergency Revit upgrade across the office took four hours on a Monday morning. The BIM Manager implemented the written upgrade protocol described in Anti-Pattern 4 immediately afterward.

Case Study 2: The Cross-Continent Infrastructure Project

Profile: An infrastructure project involving an owner's representative in Houston, a lead structural engineer in Toronto, and two specialty subconsultants in London and Sydney. 14 Revit-authoring users across four organisations and four time zones. Model: a federated set of 6 Revit models ranging from 80 to 280 MB. Project duration: 30 months.

The baseline problem: The project began with a SharePoint-based file exchange workflow — each discipline emailed or uploaded updated Revit files to SharePoint, and other disciplines manually re-linked them. By month four, the structural team was working with an architectural model two weeks out of date and had not noticed. A coordination issue was discovered in the field that traced back to an architectural change visible in the 2-week-old snapshot. The rework cost was six figures.

The migration: All four firms agreed to migrate to FDC at the end of DD phase. Each firm purchased FDC licenses for their Revit-authoring users (3–5 users per firm). The project administrator set up Teams in Forma for each discipline. The Design Collaboration module was configured with a biweekly package cadence.

Measurable outcomes: The biweekly package cadence meant no discipline was ever more than two weeks behind on model changes from another discipline — and the comparison viewer made it explicit what had changed since the last consumed package. The Houston owner's representative, who had no Revit license, could track all model handoffs and published model state through the Forma web interface using their Autodesk Docs access (included in AEC Collection, no additional cost).

The time zone factor: Cloud worksharing's location-agnostic architecture meant the Sydney team's working hours (which overlapped with London's morning for only two hours) were no longer a hard constraint. The Sydney team synced on their schedule; the London team synced on theirs. Neither team blocked the other. On the old SharePoint workflow, the limited overlap window had become a daily coordination meeting that consumed more time than the actual coordination.

Total additional cost: 14 FDC users at approximately US$870/user/year (10-pack rate across all firms) = approximately US$12,180/year. Total project cost over 30 months: approximately US$30,500. Against the six-figure rework event in month four (which would likely have been prevented by the package workflow's change review step), this is a straightforward ROI calculation.

Case Study 3: The Firm That Should Have Stayed Local

Profile: 4-person residential architecture practice, same studio, Revit models under 80 MB, no external consultants, no remote work. Annual BIM revenue: US$380,000. Average project duration: 12 months.

The decision: The BIM Manager attended a training event on FDC and returned enthusiastic. Firm purchased a 10-pack of FDC licenses at approximately US$8,695/year. (A 4-user firm in a 10-pack is paying for 6 unused seats.)

The reality: The firm's projects were already performing well on local worksharing. Models were small. Team was co-located. Sync times were under 60 seconds. The FDC licenses unlocked no new capabilities that the firm's project profile actually needed. The Design Collaboration package workflow added process overhead (publish, package, share steps) that three of the four team members found tedious compared to "just open the central file."

The outcome: After 12 months, the firm downgraded to a 5-pack of FDC licenses (paying ~US$4,350/year) for the possibility of occasional remote work and then, after a further 6 months, cancelled the FDC subscription entirely and returned to a local NAS with the central file. The BIM Manager concluded: "FDC is genuinely excellent for what it does. What it does is not what we needed."

The lesson: Cloud worksharing is not universally superior. For co-located teams on small models with no external collaboration requirements, the license cost adds real money for marginal or zero benefit. The decision matrix exists precisely to identify these cases.

Case Study 4: The Government Project with Data Residency Requirements

Profile: A public sector infrastructure project in Germany. Owner required all project data to be stored within the EU. Prime contractor is a German engineering firm; a specialist subconsultant is based in the United States.

The compliance challenge: The German procurement terms required a written data processing agreement confirming EU data residency. The prime contractor needed to verify that Autodesk's EU data residency option (Frankfurt data centre) covered both the Revit Cloud Worksharing layer (RCW server) and the Forma Data Management layer.

The resolution: Autodesk's regional data offering documentation (updated late 2025) confirmed that the EU region covers both the RCW server and Forma Data Management, meaning all project model data at rest is stored in the EU. The US-based subconsultant could co-author the model using their US-based Revit installation; the data at rest was still EU-resident. Autodesk's BCR framework (approved by the Irish Data Protection Commission) governed the transatlantic data transfer for processing.

The operational outcome: The data residency requirement was met within the standard FDC product offering, with no custom contracts or exceptions required beyond the standard Data Processing Agreement available from Autodesk's trust portal. The prime contractor's legal team reviewed and approved the arrangement in approximately three weeks.

What this case illustrates: Data residency requirements are a real constraint for government and regulated-sector projects, but they are no longer a blocking obstacle to cloud worksharing in most EU, UK, and several other jurisdictions. The practical requirement is to verify the regional data storage configuration at project setup, not to assume that cloud worksharing is non-compliant.

Part 6: Limits and Caveats

Joint Venture (JV) Complexity

JV projects present a specific governance challenge that neither local nor cloud worksharing fully resolves. In a JV, two or more organisations share project ownership, IP, and liability. The question of which organisation's Forma hub hosts the project, who controls the project administrator role, and which organisation's subscription covers the FDC licenses for users from both firms has no clean default answer.

The typical approach is for the lead JV partner to host the Forma project and to invite the secondary partner's users as external members. Each user from the secondary partner needs either their own FDC license (which they bring from their organisation's subscription) or a license purchased by the lead partner specifically for the project. The second approach raises questions about IP ownership and data access after project completion.

There is no Autodesk-native "JV workspace" concept that cleanly partitions data ownership between two organisations within a single project. JV projects on Forma require explicit written agreements between the parties on data ownership, access rights on project completion, and license responsibility — agreements that legal teams need to review before project setup, not after.

The "No One Knows Who Owns What" Problem

Forma project access management is straightforward in concept but can become chaotic on long projects with high team turnover. Users who leave a firm still have access to the Forma project unless a project administrator explicitly removes them. Unlike a file server (where IT can disable the AD account and immediately revoke access), Forma access is managed at the project level by the project administrator — who is often a BIM Manager or project architect, not IT staff.

Best practice: include a "departing user" protocol in the BIM Execution Plan, with a named project administrator responsible for revoking access within 24 hours of departure. Autodesk does not automatically revoke project access when a user's license lapses; access and license are managed separately.

Performance on Very Large Federated Models

Despite cloud worksharing's architectural advantages, extremely large federated model sets — 10+ discipline models, total linked model size exceeding 2 GB — can hit practical limits. The first-open cold-sync time for each model in the set is additive. A coordination meeting that requires a project manager to open all 10 models simultaneously can take 90 minutes of cold-sync downloads.

The mitigation is aggressive model decomposition and disciplined use of worksets to manage what is loaded. Detaching and reattaching links by workset (rather than loading all links at all times) reduces the practical working footprint. But there is a real ceiling for very large federated models, and teams approaching that ceiling should evaluate whether a dedicated model coordination platform (Navisworks, Forma Model Management, Solibri) can carry some of the coordination load, freeing the Revit models from the need to be fully assembled in Revit for every coordination check.

Subscription Risk

Forma Design Collaboration is a subscription product. If a firm fails to renew, or if Autodesk discontinues or substantially changes the product, teams mid-project need a path to export and continue work. Autodesk allows cloud models to be downloaded to local .rvt files at any time from the Forma interface — this is the exit ramp that removes the "locked in the cloud" concern. That said, teams should test this export process before they need it, and should include a data export clause in their BIM Execution Plans for long projects.

Part 7: Acceptance Test for Sync Time

The following PowerShell script provides a structured acceptance test for cloud worksharing sync performance. Run it at project setup, after any significant model growth milestone, and whenever a user reports sync performance degradation.

# Revit Cloud Worksharing — Sync Time Acceptance Test
# -------------------------------------------------------
# PURPOSE: Validate that sync time is within acceptable bounds for the
# current model size and connection profile. Run after initial project
# setup and at each major model milestone (SD, DD, CD).
#
# REQUIREMENTS:
#   - Revit must be installed and the cloud model must already be open
#   - PowerShell 5.1+ (built into Windows)
#   - The Worksharing Monitor log path must be accessible
#
# USAGE:
#   .\Test-SyncPerformance.ps1 -ModelSizeMB 280 -TeamSize 8 -ConnectionMbps 50
#
# ACCEPTANCE CRITERIA (industry practice, not Autodesk benchmarks):
#   Small model (<100 MB):   SWC should complete in < 3 min on >=20 Mbps
#   Medium model (100-300 MB): SWC should complete in < 8 min on >=20 Mbps
#   Large model (300-500 MB):  SWC should complete in < 15 min on >=20 Mbps
#   Very large (>500 MB):      Flag for model decomposition review
 
param(
    [Parameter(Mandatory)]
    [float]$ModelSizeMB,
 
    [Parameter(Mandatory)]
    [int]$TeamSize,
 
    [Parameter(Mandatory)]
    [float]$ConnectionMbps,
 
    [string]$LogOutputPath = "$env:USERPROFILE\Desktop\SyncAcceptanceTest_$(Get-Date -Format 'yyyyMMdd_HHmmss').txt"
)
 
$results = [System.Collections.Generic.List[string]]::new()
$pass    = $true
 
function Write-Result {
    param([string]$Message, [string]$Level = "INFO")
    $line = "[$Level] $Message"
    $results.Add($line)
    $color = switch ($Level) {
        "PASS" { "Green" }
        "WARN" { "Yellow" }
        "FAIL" { "Red" }
        default { "White" }
    }
    Write-Host $line -ForegroundColor $color
}
 
$results.Add("=== Revit Cloud Worksharing — Sync Time Acceptance Test ===")
$results.Add("Run at: $(Get-Date -Format 'yyyy-MM-dd HH:mm:ss')")
$results.Add("Model size: $ModelSizeMB MB | Team size: $TeamSize users | Connection: $ConnectionMbps Mbps")
$results.Add("")
 
# --- 1. Model size category ---
$results.Add("--- Model Size Assessment ---")
if ($ModelSizeMB -lt 100) {
    Write-Result "Model is SMALL (< 100 MB). Acceptable SWC target: < 3 minutes." "PASS"
    $syncThresholdMin = 3
} elseif ($ModelSizeMB -lt 300) {
    Write-Result "Model is MEDIUM (100–300 MB). Acceptable SWC target: < 8 minutes." "INFO"
    $syncThresholdMin = 8
} elseif ($ModelSizeMB -lt 500) {
    Write-Result "Model is LARGE (300–500 MB). Acceptable SWC target: < 15 minutes." "WARN"
    $syncThresholdMin = 15
} else {
    Write-Result "Model is VERY LARGE (> 500 MB). Recommend model decomposition review. SWC target: best effort." "FAIL"
    $syncThresholdMin = 25
    $pass = $false
}
 
# --- 2. Bandwidth adequacy ---
$results.Add("")
$results.Add("--- Network Adequacy ---")
# Rough estimate: SWC transfers ~15–20% of model size per sync (delta-based)
$estimatedDeltaMB   = $ModelSizeMB * 0.18
$estimatedTransferSec = ($estimatedDeltaMB * 8) / $ConnectionMbps   # MB -> Mb, divided by Mbps
$estimatedTransferMin = [math]::Round($estimatedTransferSec / 60, 1)
 
Write-Result "Estimated delta per sync: ~$([math]::Round($estimatedDeltaMB, 0)) MB (18% of model, typical daily changeset)." "INFO"
Write-Result "Estimated transfer time at $ConnectionMbps Mbps: ~$estimatedTransferMin minutes (network component only)." "INFO"
 
if ($ConnectionMbps -lt 10) {
    Write-Result "Connection speed ($ConnectionMbps Mbps) is below minimum recommendation (20 Mbps). Expect slow syncs." "FAIL"
    $pass = $false
} elseif ($ConnectionMbps -lt 20) {
    Write-Result "Connection speed ($ConnectionMbps Mbps) is marginal. Sync may be slow under load." "WARN"
} else {
    Write-Result "Connection speed ($ConnectionMbps Mbps) meets or exceeds 20 Mbps recommendation." "PASS"
}
 
# --- 3. Team concurrency assessment ---
$results.Add("")
$results.Add("--- Concurrency Assessment ---")
if ($TeamSize -le 5) {
    Write-Result "Team size $TeamSize: Low concurrency risk. SWC queue impact minimal." "PASS"
} elseif ($TeamSize -le 12) {
    Write-Result "Team size $TeamSize: Moderate concurrency. Recommend staggered sync schedule. Cloud worksharing's parallel sync handles this well." "INFO"
} else {
    Write-Result "Team size $TeamSize: High concurrency. Model decomposition into federated discipline models strongly recommended if not already implemented." "WARN"
}
 
# --- 4. Manual sync timing prompt ---
$results.Add("")
$results.Add("--- Manual Sync Timing ---")
Write-Result "ACTION REQUIRED: Perform one Synchronize with Central now in Revit and record the time." "INFO"
Write-Result "Expected acceptable range: < $syncThresholdMin minutes for this model size." "INFO"
$results.Add("")
$actualTimeStr = Read-Host "Enter the observed SWC time in minutes (or press Enter to skip)"
if ($actualTimeStr -match '^\d+(\.\d+)?$') {
    $actualTimeMin = [float]$actualTimeStr
    if ($actualTimeMin -le $syncThresholdMin) {
        Write-Result "Observed SWC time ($actualTimeMin min) is within the acceptable range (< $syncThresholdMin min). PASS." "PASS"
    } elseif ($actualTimeMin -le ($syncThresholdMin * 1.5)) {
        Write-Result "Observed SWC time ($actualTimeMin min) slightly exceeds target (< $syncThresholdMin min). Monitor and consider model health audit." "WARN"
    } else {
        Write-Result "Observed SWC time ($actualTimeMin min) significantly exceeds target (< $syncThresholdMin min). Model health audit required." "FAIL"
        $pass = $false
    }
} else {
    Write-Result "Sync time not recorded. Run audit manually and compare against target: < $syncThresholdMin minutes." "INFO"
}
 
# --- 5. Final verdict ---
$results.Add("")
$results.Add("=== RESULT: $(if ($pass) { 'ACCEPTABLE' } else { 'ACTION REQUIRED' }) ===")
if (-not $pass) {
    $results.Add("One or more checks failed or model is very large. Review FAIL/WARN items above.")
}
 
$results | Out-File $LogOutputPath -Encoding UTF8
Write-Host "`nReport saved to: $LogOutputPath" -ForegroundColor Cyan

Sources and Further Reading

The following sources were consulted in the preparation of this article. URLs were verified accessible at time of writing (June 2026).

Primary Sources

1. Autodesk Help — Revit Cloud Worksharing (Revit 2026) https://help.autodesk.com/view/RVT/2026/ENU/?contextId=A360_ABOUT_COLLAB_REVIT The authoritative Autodesk documentation for Revit Cloud Worksharing, including Desktop Connector requirements, sync mechanics, and version compatibility.

2. Autodesk Support — Best Practices for Cloud Worksharing in Revit https://www.autodesk.com/support/technical/article/caas/sfdcarticles/sfdcarticles/Revit-Cloud-Work-Sharing-Best-practices.html Official Autodesk best practices article covering model opening protocol, sync hygiene, and common error patterns.

3. Autodesk Support — Why Revit Models Get Corrupt While Working Over VPN https://resources.imaginit.com/support-blog/why-do-revit-models-get-corrupt-while-working-over-a-vpn-connection Technical explanation of the SMB/WAN incompatibility underpinning VPN-based central file corruption.

4. IMAGINiT — Revit Cloud Model: Save vs. Sync vs. Publish Simplified https://resources.imaginit.com/support-blog/revit-cloud-model-save-vs-sync-vs-publish-simplified The clearest practitioner-authored explanation of the three-layer cloud model architecture and the distinction between the three operations.

5. Autodesk — Autodesk Construction Cloud Is Now Autodesk Forma (Architosh coverage) https://architosh.com/2026/03/autodesk-construction-cloud-acc-is-now-autodesk-forma/ Coverage of the March 2026 ACC → Autodesk Forma rebrand and its immediate impact on BIM Collaborate Pro → Forma Design Collaboration naming.

6. Novedge — BIM Collaborate Pro Subscription Pricing https://novedge.com/products/buy-bim-collaborate-pro-subscription Authorized reseller pricing for BIM Collaborate Pro (now Forma Design Collaboration). Single-user and pack pricing data sourced here. Prices subject to change; verify with Autodesk or reseller before budgeting.

7. Autodesk Trust Center — Regional Data Storage https://help.autodesk.com/view/DOCS/ENU/?guid=Regional_Data_Storage Autodesk's documentation of available data residency regions for Forma/ACC products, including the EU, UK, Germany, India, Japan, Canada, and Australia options.

8. CADpro — Revit Cloud Worksharing: Best Practices for Collaboration https://cadpro.io/knowledge-hub/revit-cloud-worksharing/ Practitioner-authored guide covering the two-server architecture, sync workflow, publish protocol, and Desktop Connector dependency.

9. BIM NYC — Design Collaboration: A Workflow for Better Collaboration https://www.bimnyc.com/post/design-collaboration-a-workflow-for-better-collaboration Practical walkthrough of the Publish → Package → Share → Consume workflow in Forma Design Collaboration.

10. Enginero — Common Pitfalls in Revit Cloud Work Sharing https://www.enginero.com/blogs/common-pitfalls-in-revit-cloud-work-sharing/ Practitioner documentation of the ten most common cloud worksharing failure modes, with technical detail on root causes.

11. Hagerman — 10 Common Revit Cloud Model Mistakes https://blog.hagerman.com/10-common-revit-cloud-model-mistakes-and-how-to-avoid-them Complementary practitioner list with emphasis on Revit 2025/2026 context and version lock risks.

12. Autodesk Support — What Are the Differences Between Revit Cloud Worksharing and Revit Server https://www.autodesk.com/support/technical/article/caas/sfdcarticles/sfdcarticles/What-are-the-differences-between-Revit-Server-and-Collaboration-for-Revit.html Official comparison of the two server-based collaboration approaches.

Further Reading

• Autodesk Forma pricing: https://construction.autodesk.com/pricing/ — Contact Autodesk or an authorized reseller for current per-seat pricing; the public pricing page requires a quote request.
• Autodesk Trust Center (GDPR, BCR): https://www.autodesk.com/trust/compliance — Binding Corporate Rules documentation and compliance certificates.
• Autodesk expanded regional offerings (UK, Germany, India, Japan, Canada): https://adsknews.autodesk.com/en/news/expanded-regional-offerings/
• Strand & Co — Implementing Revit Cloud Worksharing for Distributed Teams: https://strand-co.com/blogs/implementing-revit-cloud-worksharing/ — Field implementation guide with bandwidth and best practice recommendations.

This article reflects Autodesk product naming and pricing data as of June 2026. The Autodesk Forma rebrand (formerly ACC) was completed March 24, 2026. License pricing cited uses authorized reseller data; always verify current pricing with Autodesk or a reseller before budgeting. Sync performance figures represent typical practitioner-reported ranges, not Autodesk-published benchmarks, and are sensitive to model health, network conditions, and changeset size.