Proactive Worksets Shared Multi-user Setup

TL;DR

• Put the practice root on a real shared location that every coordinator reaches by the same kind of path, such as a UNC network share (\\server\BIM\Proactive), a mapped network drive, or an ACC/Desktop-Connector folder.
• Create each project once. The first coordinator creates it; everyone else opens it from the same root (they do not create their own copy).
• Point Config Manager at the shared root with Projects > Change…. Pointing at a root a colleague already set up is how you "join" their shared project set.
• OneDrive/Dropbox/Desktop folders are not supported for multi-user sharing (see below).

Why the practice root matters

Proactive Worksets keeps a practice root, which is a single shared folder that holds every project's config package and the shared project registry (projects.index.json). It is stored per machine at:

%ProgramData%\Proactive\settings.json

Every coordinator's Config Manager reads its projects from that root. If two coordinators point at different roots, they see different project lists. Each project also gets its own internal identity (projectIdentifier) when it is created. Two separately-created "same" projects have different identities, so linking one project's config onto a model bound to the other is a cross-project move, and Revit asks you to confirm it:

This model is governed by QIC 01: Riverside Tower · Architecture.

You selected a configuration from QIC 07: Harbour Point · Structure.

That prompt is the runtime catching a cross-project mix-up. You can confirm it for a genuine migration, and the model is never left ungoverned in between. If you are seeing it because two coordinators created the "same" project twice, confirming only spreads the split. The fix is upstream: share one root and one project, not two roots and two projects.

Supported: one real shared location

Use a location that is genuinely shared and reachable by all coordinators:

Setup:

1. One coordinator picks the shared location on first run (or via Projects > Change…).
2. Other coordinators open Config Manager, choose Projects > Change…, and point at the same shared location. They now see the same projects.
3. To add a project, one person uses + New Project. Everyone else sees it and opens it. They do not create their own.

The current root is shown at the top of the Projects screen ("Shared root: …") so you can confirm at a glance which location you are reading from.

Not supported: OneDrive / Dropbox / Desktop folders

A path under your user profile, such as ...\OneDrive\Desktop\..., ...\Documents\..., or Dropbox, is local-only from Proactive's point of view, even when a cloud service syncs it. Config Manager flags these paths with a warning, because:

• Each machine's copy lives at a different absolute path (C:\Users\alice\OneDrive\… vs C:\Users\bob\OneDrive\…), so a stored config reference written by one user does not resolve for another.
• Cloud sync reconciles files after the fact with last-writer-wins and *-CONFLICT-* copies. There is no live shared registry, so one coordinator's new project can silently overwrite or fail to appear for another.

If you accept the local-only warning anyway, the tools still run, but multi-user sharing will not work reliably. For a single-machine setup it is fine.

Portable references (how a linked config resolves on every machine)

When you link a config to a model with Load Configuration…, Proactive Worksets stores the reference relative to the practice root (shown as ${PRACTICE}\Projects\…) whenever the config lives under that root. Each machine rebases that relative reference onto its own practice root, so the same reference resolves correctly even when machine A uses a UNC path and machine B uses a mapped drive.

• A config outside the practice root is stored as a plain absolute path (and Load Configuration… warns if that path looks local-only).
• If a machine has no practice root configured, a portable reference cannot be resolved there. Set the practice root in Config Manager (or re-link) to fix it.

You can confirm exactly what a model is reading with Workset > Show Current Configuration in Revit: it shows the stored reference, the path it resolves to on this machine, the project identity, and the live runtime status. Workset > Unload Configuration removes the reference entirely. Note that it leaves the model governed by nothing until you link again, and that state syncs to central, so prefer linking the correct config directly over clearing first.

Quick troubleshooting