Autodesk Revit Quiz: Synchronizing With Central
10 questions · exam conditions
0:00
Synchronizing With CentralQuestion 1 of 10

Marco owns the user-created workset Interiors and has also borrowed several elements on the Shared Levels and Grids workset. After completing his tasks, he synchronizes. Other users need both the Interiors workset and the individually borrowed elements, but Marco must retain ownership of project standards worksets.

Which relinquishment settings should Marco use during synchronization?

Relinquish User-created Worksets and Borrowed Elements, but retain the other categories.
Relinquish Project Standards Worksets and View Worksets, but retain borrowed elements.
Relinquish only User-created Worksets, because borrowed elements are released automatically with them.
Relinquish only Borrowed Elements, because synchronizing automatically releases owned user-created worksets.
← Back to quizzes

Autodesk Revit Quiz

Autodesk Revit Quiz: Synchronizing With Central

Practice Synchronizing With Central in Autodesk Revit with focused quiz questions that help you check what you know, review explanations, and build confidence with test-style prompts.

What this quiz covers

This quiz focuses on Synchronizing With Central, giving you a quick way to practice the rules, question types, and explanations that matter most for Autodesk Revit.

How to use this quiz

Try each quiz question before looking at the correct answer. Use the explanations to review missed ideas, then come back to similar questions until the pattern feels familiar.

All questions

Question 1

Marco owns the user-created workset Interiors and has also borrowed several elements on the Shared Levels and Grids workset. After completing his tasks, he synchronizes. Other users need both the Interiors workset and the individually borrowed elements, but Marco must retain ownership of project standards worksets.

Which relinquishment settings should Marco use during synchronization?

  1. Relinquish User-created Worksets and Borrowed Elements, but retain the other categories. (correct answer)
  2. Relinquish Project Standards Worksets and View Worksets, but retain borrowed elements.
  3. Relinquish only User-created Worksets, because borrowed elements are released automatically with them.
  4. Relinquish only Borrowed Elements, because synchronizing automatically releases owned user-created worksets.
Explanation: When working in a Revit worksharing environment, synchronizing with central doesn't automatically release everything you own — you must explicitly choose what to relinquish. The key is understanding the three relinquishable categories: User-created Worksets (custom worksets like "Interiors"), Borrowed Elements (individual elements checked out from any workset), and Project Standards Worksets (families, line styles, etc. — which Marco must keep). Answer A is correct because Marco's situation has two distinct things to release: ownership of the Interiors workset (a user-created workset) and the individual elements he borrowed from Shared Levels and Grids (borrowed elements). These are tracked separately in Revit, so both checkboxes must be selected. Relinquishing one does not automatically relinquish the other. Answer B is wrong because relinquishing Project Standards Worksets directly contradicts the scenario's requirement that Marco retain those. View Worksets aren't mentioned as something others need, making this selection both incorrect and irrelevant. Answer C is a common trap — it implies borrowed elements are bundled under user-created worksets. They aren't. Borrowed elements are individually tracked regardless of which workset they belong to, and releasing a workset does not release separately borrowed elements within it. Answer D reverses the logic of C, claiming synchronization auto-releases user-created worksets. This is false — Revit requires explicit relinquishment of workset ownership; it is never automatic. Study tip: Remember that in Revit, workset ownership and borrowed element checkouts are always tracked independently. When answering relinquishment questions, ask yourself: "What category does each item fall under?" and check each one separately.

Question 2

A central model became corrupted and was replaced with a restored backup from the previous evening. All of Lee's work had already been synchronized before the failure. When Lee opens the existing local file, Revit reports that it is incompatible with the current central model.

What is the most appropriate resolution for Lee?

  1. Create a new local model from the restored central model and discontinue the old local file. (correct answer)
  2. Detach the old local model, preserve worksets, and overwrite the restored central model.
  3. Rename the old local model and synchronize it with the restored central model again.
  4. Use Reload Latest in the old local model until its central identifiers are updated.
Explanation: Whenever you see a question about worksharing and local/central model conflicts in Revit, focus on one key principle: a local file is tightly bound to its central model through a unique set of internal identifiers (GUIDs). When the central model is replaced — even with a valid backup — those identifiers no longer match the existing local file, making the local file permanently incompatible. The correct resolution is A: create a new local file from the restored central model and abandon the old one. Since the passage confirms Lee had already synchronized all work before the failure, that work is safely stored in the restored central model. Creating a new local file from the restored central picks up exactly where things left off, with no data loss and no compatibility errors. B is dangerous and backwards — detaching the old local and overwriting the restored central would destroy the backup and potentially introduce corrupted data, defeating the entire purpose of the restore operation. C is a common misconception: renaming a local file changes nothing about its internal identifiers. Revit doesn't care about the filename; it checks the embedded GUIDs, so renaming will not resolve the incompatibility. D misunderstands what "Reload Latest" does — that command refreshes linked files or workset visibility, not the central model binding. It has no mechanism to re-synchronize incompatible identifiers. A good rule of thumb to remember: when the central model is replaced or restored, all existing local files become orphaned and must be recreated. On the exam, any option that tries to "repair" or "force" an old local file into compatibility is a trap.

Question 3

Omar has made no changes in his local model. He knows that several teammates have synchronized, and he needs their latest changes before beginning a coordinated task. He does not want to create an unnecessary synchronization entry or relinquish any current ownership.

Which workflow best meets Omar's requirement?

  1. Use Synchronize with Central with every relinquishment category selected.
  2. Use Reload Latest now, and synchronize later when he has changes to publish. (correct answer)
  3. Save and close the local model, and then reopen the same local file offline.
  4. Use Relinquish All Mine, and continue without retrieving central changes.
Explanation: When working in a Revit workshared project, it's important to distinguish between receiving changes from central and publishing your own changes to central. These are two separate actions, and mixing them up is a common source of confusion on exam questions like this one. Omar's situation is straightforward: he has nothing to publish, but he needs to pull in his teammates' latest work. The right tool here is Reload Latest (B). This command fetches the current state of the central model into Omar's local file without creating a new synchronization entry and without relinquishing any borrowed elements or workset ownership. It's a one-way, non-destructive refresh — exactly what the scenario describes. Choice A is wrong because Synchronize with Central does far more than Omar needs. It publishes his local changes (there are none), creates a synchronization entry in the file's history, and — if all relinquishment categories are checked — gives up his ownership of worksets and elements. This violates his requirement to avoid unnecessary entries and retain ownership. Choice C is a trap. Closing and reopening the local file does not fetch new changes from central; it simply reloads your own local save. You'd still be working with stale data. Choice D, Relinquish All Mine, moves in the opposite direction entirely — it surrenders ownership without retrieving anything from central. This would leave Omar with less than he started with and no updated data. As a study tip, remember this rule of thumb: Reload Latest = receive only; Synchronize with Central = send and receive. If a scenario says "no changes to publish," Reload Latest is almost always the answer.

Question 4

A project manager notices that the central model has grown substantially. The team wants to reduce its file size, but users are actively synchronizing throughout most of the day.

How should the Compact Central Model option be used most appropriately?

  1. Enable it after detaching the local model, because only detached files can compact central data.
  2. Enable it on every user's synchronization, because compaction reduces each operation's duration.
  3. Enable it only while using Reload Latest, because synchronization cannot compact the central model.
  4. Enable it during a planned low-activity synchronization, accepting that the operation may take longer. (correct answer)
Explanation: When working with Revit worksharing, you need to understand that the central model is a shared file that all team members synchronize to — and over time, it accumulates deleted elements, redundant data, and internal fragmentation that bloat its file size. The Compact Central Model option addresses this by performing a deeper cleanup during synchronization, but it comes at a cost: the operation takes significantly longer than a standard sync. This is why D is correct. Compacting should be scheduled during a planned low-activity window — ideally when few or no users are actively syncing — so the longer operation doesn't create bottlenecks or conflicts for the rest of the team. One user enabling compaction during an off-peak sync is the intended workflow. A is wrong because compaction applies to the central model during synchronization — not to detached files. Detaching a local model creates a standalone copy and has nothing to do with reducing the central model's size. B is wrong because enabling compaction on every user's sync is counterproductive. Compaction extends sync duration, so running it constantly would slow down the entire team rather than help them. It's a periodic maintenance task, not a routine toggle. C is wrong because Reload Latest only pulls updates from the central model to your local copy — it doesn't write anything back, so it cannot trigger compaction on the central file at all. As a study tip, remember that Revit file management questions often test whether you understand the cost of maintenance operations. Compaction is powerful but expensive — timing it correctly is the entire point.

Question 5

After several hours of work, Sofia attempts to synchronize and receives a message that the central model cannot be reached because the network connection has failed. Her local model remains open and contains all of her modifications.

Which action best protects Sofia's work while avoiding damage to the shared model?

  1. Detach the open local model and distribute it as the new central model without coordination.
  2. Use Save As to overwrite the central-model path with her current local model immediately.
  3. Close without saving, create a new local model, and manually repeat all modifications.
  4. Save the local model, restore network access, and retry synchronization after confirming central availability. (correct answer)
Explanation: When working in a Revit worksharing environment, your local model is essentially a personal working copy that must periodically sync changes back to the central model — the authoritative shared file everyone collaborates through. Questions like this test whether you understand how to protect work integrity when that sync connection breaks. The safest path here is D: save the local model locally, restore network access, and retry synchronization once you've confirmed the central model is available. Your local file already contains all of Sofia's modifications safely on disk. No work is lost. Once the network returns, a standard Synchronize with Central operation merges her changes properly, preserving the worksharing history, element ownership, and everyone else's contributions. Option A is dangerous because distributing a local model as a new central without coordination would create a parallel, out-of-sync central file — effectively splitting the project and potentially overwriting teammates' work. Option B is similarly destructive: overwriting the central-model path with a local file bypasses Revit's worksharing protocols entirely, which could corrupt the central model or erase other users' synchronized changes. Option C is the most wasteful choice — closing without saving discards all of Sofia's work unnecessarily, since the local model is still open and intact; manually repeating modifications wastes hours and introduces human error. The key principle to remember: the local model is your safety net. A failed sync does not mean lost work. Always save locally first, then address the root cause (network access), and only sync after confirming the central model is healthy. Never bypass the central model's worksharing structure under pressure — that's when irreversible damage happens.

Question 6

During Synchronize with Central, Revit reports that the central model is currently being accessed by another user. The user's local model remains open, and no message indicates that the central file is damaged or unavailable.

What is the best initial response?

  1. Wait briefly and retry synchronization after the other central-model operation finishes. (correct answer)
  2. Detach the local model and immediately save it over the existing central model.
  3. Delete the local model and recreate it before checking whether synchronization can resume.
  4. Change the Revit username and retry so the central model treats the session as new.
Explanation: When working in a Revit worksharing environment, the central model acts as the single source of truth that all team members synchronize against. Questions like this test whether you understand normal worksharing behavior versus actual errors — and whether your response is proportional to the situation. When Revit reports that the central model is being accessed by another user, this is expected, routine behavior. The worksharing system is simply protecting the central file from simultaneous write operations. The correct response is A: wait a moment and retry synchronization. Once the other user's operation completes, the file becomes available again and your sync will proceed normally. No data is lost, no file is corrupted, and no intervention is required. B is dangerous — detaching your local model and saving it over the central file would overwrite everyone else's work and destroy the worksharing history. This is one of the most harmful actions you can take in a collaborative Revit project and should never be a first response to a routine access conflict. C is equally disproportionate; deleting and recreating your local model wastes significant time and is only warranted if the local file itself is corrupted, which the scenario doesn't describe. D misunderstands how worksharing identity works — changing your Revit username doesn't create a new session that bypasses file locking; it actually causes permission and element ownership conflicts, potentially corrupting the central model. A useful rule of thumb: if Revit reports a user conflict (not a file error), your first move is always to wait and retry. Reserve destructive actions for confirmed file corruption only.

Question 7

Evan's existing local model was created under a different Revit username. All work from that file was previously synchronized, and Evan now receives a username-related warning when attempting to work with it.

What is the most reliable way for Evan to resume work without creating ownership ambiguity?

  1. Rename the existing local file so Revit assigns ownership to the current username.
  2. Change to another teammate's username and continue using the existing local model.
  3. Verify the current username and create a fresh local model from the central model. (correct answer)
  4. Detach the existing local file and overwrite the central model under the new username.
Explanation: When working in a Revit worksharing environment, local files are tied to the username that created them. If your current username doesn't match the one embedded in an existing local file, Revit flags an ownership conflict — it can't reliably assign element permissions, borrowed elements, or editing rights. The clean solution is always to start fresh. The correct approach, C, resolves this by first confirming your active Revit username (under Options → General), then creating a brand-new local copy from the central model. This ensures every element checkout and ownership record is cleanly associated with your current credentials — no ambiguity, no inherited permissions from a ghost user. A is a common misconception. Simply renaming the local file doesn't change the internal username metadata Revit embedded when the file was first created. The ownership conflict persists beneath the surface — you've only changed the filename, not the authorship data. B is a serious workflow violation. Borrowing a teammate's username to sidestep the warning introduces false ownership records into the central model, which can corrupt worksharing logs and cause genuine confusion about who owns which elements. This is never an acceptable workaround. D is dangerous. Detaching a local file severs it from the central model entirely, and overwriting the central model with it could erase all other contributors' synchronized work. This is a destructive action reserved for very specific scenarios — never for a simple username mismatch. A good rule of thumb: when identity and ownership are in question, always go back to the central model and start clean. Local files are disposable; the central model is the source of truth.

Question 8

Nina has modified several borrowed elements in her local model. Other team members have synchronized changes to different worksets since Nina opened the model. Nina now needs to publish her modifications and continue working with the team's latest changes.

Which action most directly accomplishes both objectives in one operation?

  1. Use Reload Latest, and then save the local model without synchronizing.
  2. Use Synchronize with Central, keeping the required ownership until later. (correct answer)
  3. Save the local model, and then reopen it from the same local file.
  4. Use Relinquish All Mine, and then use Reload Latest.
Explanation: When working in a Revit worksharing environment, you need to understand what "Synchronize with Central" (SWC) actually does versus other file operations. The key distinction is that SWC is a bidirectional operation: it simultaneously pushes your local changes to the central model and pulls down changes others have published since you last synced — all in a single step. This makes B the correct answer. When Nina uses Synchronize with Central, her borrowed element modifications are uploaded to the central model, and her local file is updated with every change her teammates have already synchronized. The option to "keep required ownership" simply means she retains element borrowing permissions she still needs to continue working — this is a legitimate, built-in choice within the SWC dialog and doesn't compromise the operation. A is flawed because Reload Latest is a one-way pull: it downloads teammates' changes but does not publish Nina's modifications to the central model. Her work remains local only. C is simply ineffective. Saving and reopening the same local file neither publishes changes to the central model nor retrieves newer changes from it. The local file is not the central file. D describes two separate operations, and critically, Relinquish All Mine surrenders element ownership before Nina has published her changes — potentially losing or conflicting her work. The sequence is backwards and destructive. Study tip: Whenever a Revit question asks how to both publish and receive changes simultaneously, Synchronize with Central is almost always the answer — it's the only worksharing command that runs in both directions at once.

Question 9

A multidisciplinary team is investigating when a coordinated grid adjustment was published. Before synchronizing the adjustment, the modeler wants to leave useful information that can later help identify the relevant central-model transaction.

Which action should the modeler take?

  1. Place a text note in a private working view before using Reload Latest.
  2. Rename the local model with the adjustment description before completing the operation.
  3. Enter a descriptive comment in the Synchronize with Central dialog before completing the operation. (correct answer)
  4. Add the description to the Revit username before opening the central model.
Explanation: When working in a Revit worksharing environment, the central model maintains a transaction history of every synchronization event. The key concept here is that this history is the primary audit trail for a multidisciplinary team trying to trace when specific changes — like a grid adjustment — were committed to the central model. Knowing how to tag those transactions meaningfully is an essential coordination skill. The correct approach is C: entering a descriptive comment in the Synchronize with Central dialog. When you synchronize, Revit prompts you with a dialog that includes a Comment field specifically designed to annotate that transaction. This comment is stored in the central model's worksharing log and appears in the Worksharing Monitor and transaction history, making it directly searchable by any team member investigating the timeline later. Option A is ineffective because a text note in a private working view is invisible to other team members and completely unrelated to the synchronization record. Reload Latest doesn't write anything to the central model at all. Option B is a trap — renaming the local file affects only your local copy and has no connection to the central model's transaction log; it disappears once you synchronize. Option D is impractical and disruptive: changing your Revit username mid-project would corrupt your worksharing permissions and ownership records, and usernames aren't designed to carry descriptive change notes. As a study tip, remember that in Revit worksharing questions, the Synchronize with Central dialog is the primary gateway for committing data to the central model — any action meant to annotate the central record must pass through it.

Question 10

Priya has unsynchronized modifications to a wall she currently owns. Daniel sends an editing request for that wall because he must adjust its constraints immediately. Priya has finished her work on the wall and wants to preserve it.

What should Priya do before Daniel edits the wall?

  1. Synchronize her changes and relinquish the wall, allowing Daniel to obtain ownership afterward. (correct answer)
  2. Relinquish the wall without synchronizing, allowing Daniel's changes to replace her local modifications.
  3. Use Reload Latest and retain ownership, because Daniel can edit the wall after reloading.
  4. Save her local model and grant the request, because a local save publishes the wall changes.
Explanation: When working in a Revit workshared project, understanding the relationship between local saves, Synchronize with Central (SWC), and element ownership is essential. Whenever a question involves one user needing to hand off an owned element to another, ask yourself: has the first user's work been published to the central model yet? In Revit worksharing, changes you make locally are invisible to your teammates until you synchronize with central. Synchronizing does two things simultaneously: it publishes your edits to the central model and relinquishes your ownership of those elements (unless you choose to keep them). So if Priya synchronizes her changes, her wall modifications are safely stored in the central model, and Daniel can then request and obtain ownership to make his edits on top of her preserved work. This makes A the correct answer — it's the only workflow that protects both users' contributions. B is dangerous because relinquishing without synchronizing discards Priya's local changes entirely. Daniel would inherit a wall in its pre-Priya state, and her work is lost. C misrepresents what "Reload Latest" does — it pulls others' changes into your local model but does not transfer ownership. Priya retaining ownership means Daniel still cannot edit the wall. D contains a critical misconception: saving locally (Ctrl+S) only writes to your local file on disk. It does not publish anything to the central model, so Daniel would have no access to Priya's changes even after a local save. A useful rule of thumb: in Revit worksharing, only SWC makes your work real to the rest of the team. Local save is just a personal backup.