Autodesk Revit Quiz: Worksharing Basics
10 questions · exam conditions
0:00
Worksharing BasicsQuestion 1 of 10

A project team has developed a Revit model as a standalone file. The BIM lead now needs several team members to work in the model concurrently from a shared network location.

Which workflow correctly establishes the file-based workshared model?

Enable worksharing, save the model to the shared location as the central model, and have each user create a local model.
Save separate copies for each user, enable worksharing in each copy, and later combine the copies into one central model.
Enable worksharing, distribute copies before saving a central model, and designate the first synchronized copy as the central model.
Save the standalone model to the shared location, leave worksharing disabled, and allow all users to open that same file concurrently.
← Back to quizzes

Autodesk Revit Quiz

Autodesk Revit Quiz: Worksharing Basics

Practice Worksharing Basics 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 Worksharing Basics, 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

A project team has developed a Revit model as a standalone file. The BIM lead now needs several team members to work in the model concurrently from a shared network location.

Which workflow correctly establishes the file-based workshared model?

  1. Enable worksharing, save the model to the shared location as the central model, and have each user create a local model. (correct answer)
  2. Save separate copies for each user, enable worksharing in each copy, and later combine the copies into one central model.
  3. Enable worksharing, distribute copies before saving a central model, and designate the first synchronized copy as the central model.
  4. Save the standalone model to the shared location, leave worksharing disabled, and allow all users to open that same file concurrently.
Explanation: When a question asks about setting up worksharing in Revit, focus on the correct sequence of steps: enable worksharing first, establish the central model, then distribute local copies — order matters enormously here. The proper workflow, captured in A, follows Revit's required process exactly: you enable worksharing in the standalone file, save it to the shared network location (which designates it as the central model), and then each team member opens that central model and saves their own local copy to work from. Local copies sync changes back to the central model, allowing true concurrent collaboration. This is the foundational file-based worksharing workflow in Revit. B is wrong because worksharing cannot be meaningfully enabled in isolated copies and later "merged." Revit has no native tool to combine separately workshared files into one central model — this describes a workflow that simply doesn't exist in Revit. C reverses a critical step. You must save the central model before distributing copies to users. Distributing copies before a central model exists means no authoritative file governs synchronization, and designating a "first synchronized copy" as the central model afterward is not a valid Revit operation. D describes opening the same file simultaneously without worksharing — this is dangerous because Revit will warn users that the file is already open, and any user who saves will overwrite another's work. Worksharing exists specifically to prevent this problem. A helpful tip: on Revit exam questions about worksharing, always verify that the answer respects the sequence — enable → save central → create locals. Any answer that skips or reorders these steps is a trap.

Question 2

A user accidentally opens the central model directly instead of creating a local model. The user notices the mistake before making or saving any changes.

What should the user do to follow the recommended worksharing workflow?

  1. Keep the central model open and use Save As to create a local file after completing the current editing session.
  2. Enable worksharing again in the open central model so Revit creates a user-specific editing session automatically.
  3. Synchronize the unchanged central model once, then continue editing it because synchronization establishes local behavior.
  4. Close the central model without changes, then reopen it through Revit with Create New Local selected. (correct answer)
Explanation: Whenever you see a question about Revit worksharing workflows, focus on the fundamental rule: the central model is sacred. It serves as the shared hub for all team members, and editing it directly — rather than through a local copy — puts the entire project at risk. The safest and correct recovery in this scenario is D. Because the user caught the mistake before making or saving any changes, the central model is still pristine. The proper fix is simply to close it without saving, then reopen it using the Create New Local option in the Open dialog. This generates a properly linked local copy, preserving the central model's integrity and setting up the correct synchronization workflow going forward. A is tempting but wrong. Using Save As after editing the central model doesn't retroactively fix the problem — it creates a new file but doesn't undo the risk of having worked directly in the central model. The issue isn't the file name; it's where the editing session originated. B reflects a misunderstanding of how worksharing works. Worksharing is enabled once when the project is first set up. You cannot "re-enable" it to conjure a local session from within an already-open central model. C is a dangerous misconception. Synchronizing with Central does not convert your session into a local workflow. Synchronization pushes and pulls changes between local and central — it doesn't change what kind of file you have open. As a study tip, remember: always create local first, never edit central directly. Questions on this topic often test whether you understand why the local/central distinction matters, not just the steps.

Question 3

A workshared central model already exists on the project server. A new team member needs a working copy that remains associated with that central model.

Which method should the team member use?

  1. Copy the central file in Windows Explorer, rename the copy, and open it without using Revit's local-model option.
  2. Open another team member's local model, use Save As, and change only the user name in the file name.
  3. Select the central model in Revit's Open dialog and enable Create New Local before opening the model. (correct answer)
  4. Open the central model directly, make one local save, and continue using that same central file as the working copy.
Explanation: When working with Revit's worksharing system, the key concept to understand is how local models relate to a central model. The central model is the shared hub that stores all team members' work — no one should work in it directly. Instead, each team member needs their own local copy that stays synchronized with the central model through Save to Central operations. The correct approach is C: using Revit's built-in Create New Local checkbox in the Open dialog. When you select the central file and enable this option, Revit automatically creates a properly linked local copy, assigns your username to it, and establishes the synchronization relationship. This is the only method that correctly registers the local file with the central model from the start. A is a common but dangerous workaround. Copying the central file through Windows Explorer creates a file that looks identical but lacks the proper internal worksharing relationship. Revit won't recognize it as a legitimate local model, and you risk corrupting the central file or losing work. B creates a similar problem — another team member's local file already has their user ownership embedded in it. Simply renaming it doesn't reassign the internal permissions or properly link it to you as a new user. Ownership conflicts and permission errors will follow. D defeats the entire purpose of worksharing. Opening and working directly in the central model puts everyone else's work at risk. Revit explicitly warns against this because concurrent direct edits can corrupt the central file. Your study tip: whenever a Revit question involves worksharing, ask yourself whether the workflow uses Revit's built-in tools or tries to work around them — workarounds almost always indicate the wrong answer.

Question 4

While working in a local model, an architect has modified several rooms. Another team member has already synchronized changes to doors in the same central model. The architect wants to publish the room changes and update the local model with the latest door changes in one operation.

Which operation best meets both requirements?

  1. Use Reload Latest, and then save the local model after the incoming door changes have been processed.
  2. Use Synchronize with Central, allowing the operation to send local changes and receive current central changes. (correct answer)
  3. Use Save As on the local model, replacing the existing local file while preserving its central association.
  4. Use Relinquish All Mine, allowing ownership data and all modified room geometry to transfer to the central model.
Explanation: When working in a Revit worksharing environment, you need to understand the distinction between operations that only receive changes versus those that both send and receive. This question tests whether you recognize which single workflow accomplishes both goals simultaneously. Synchronize with Central is the operation designed to do exactly what the scenario describes: it pushes your local changes up to the central model and pulls down any changes your teammates have already synchronized — all in one step. So option B correctly meets both requirements: the architect's room changes are published to central, and the latest door changes from the central model flow back into the local file. Option A is tempting but incomplete. Reload Latest only downloads the most recent central changes into your local model — it does not publish your local modifications to central. You would still need a separate step to share your room changes, making this a two-step process, not one. Option C, Save As, creates or overwrites a local copy of the file but does not synchronize data with the central model at all. It has no mechanism for exchanging room or door changes with central. Option D, Relinquish All Mine, releases element ownership (borrowed elements and workset checkouts) back to the central model, but it does not transfer your modified geometry. Relinquishing ownership without first synchronizing means your room edits are abandoned, not published. A useful rule of thumb: whenever an exam scenario requires both contributing local changes and receiving central changes in one operation, Synchronize with Central is always the answer — it is the only Revit workflow built for that dual purpose.

Question 5

A central model must be relocated from an old project server to a new server. All users have synchronized, relinquished their elements, and closed their local models.

After the central model is correctly established at the new location, what should users do with their existing local models?

  1. Continue using them because synchronization identifies a central model by file name rather than by its saved location.
  2. Open them and use Reload Latest once, which automatically redirects each local model to the relocated central model.
  3. Discard them and create new local models from the central model at its new shared location. (correct answer)
  4. Rename them to match the relocated central model and then synchronize each one in its original folder.
Explanation: When working with Revit worksharing, it's essential to understand how local models are linked to a central model. A local model isn't just a copy of a file — it contains a hardcoded path to the specific central model it was created from. This path is embedded at the moment you create the local model, which is the key concept being tested here. When a central model is moved to a new server location, that stored path inside every existing local model becomes invalid. Even though the file name may be identical, Revit identifies the central model by its full file path, not just its name. This means old local models are essentially orphaned — they still point to an address that no longer exists. The correct action is to discard those stale local models and create fresh ones directly from the central model at its new location, making C the right answer. Answer A is wrong because Revit does not identify the central model by name alone — the full path matters. Renaming a file doesn't help if the location has changed. Answer B is misleading because "Reload Latest" refreshes model data but does not reroute a local model to a different central model path; the connection is already broken. Answer D compounds the same misconception from A, and renaming local files does nothing to repair the broken server path — synchronization would simply fail. A good rule of thumb: any time a central model moves, treat all existing local models as obsolete. Always create new locals from the relocated central file to ensure a clean, valid connection.

Question 6

User A synchronized all changes but closed a local model without relinquishing borrowed elements. User B now needs to modify one of those elements, and User A is available to resolve the issue.

Which action is the most appropriate way to make the element available to User B?

  1. Have User A open the associated local model and relinquish the borrowed elements through the central model. (correct answer)
  2. Have User B rename the element's workset so that Revit treats the element as unowned project content.
  3. Have User B create a new local model, because a newly created local automatically overrides existing element ownership.
  4. Have User A save the local model with a different file name, which transfers the borrowed elements back to the central model.
Explanation: When working with Revit worksharing, element ownership is tied to a specific user's local model. When a user borrows an element, that ownership is recorded in the central model — and it can only be released by that same user's local file. This is the core concept being tested here. The proper resolution is option A: User A needs to reopen their local model and explicitly relinquish the borrowed elements, either by using "Relinquish All Mine" or by synchronizing with the option to give up borrowed elements. Once relinquished, the central model updates to show those elements as available, and User B can then borrow them freely. Option B is wrong because renaming a workset does not affect element ownership. Workset ownership and element borrowing are separate concepts — you can't "trick" Revit into releasing borrowed elements by changing workset names. Option C is a common misconception: creating a new local model does not override existing element ownership. The central model still records User A as the borrowing owner, so User B's new local file would simply inherit the same conflict. Option D is also incorrect — saving the local file under a different name doesn't transfer borrowed elements back to the central model. Revit tracks ownership through the original local model's synchronization history, not the file name. A useful rule of thumb: borrowed elements always follow the borrower back to the central model. The only way to release them is through the original borrowing user's local file and a sync or explicit relinquishment. On the exam, any answer suggesting a workaround that bypasses that user is almost certainly wrong.

Question 7

A BIM manager needs to create an independent copy of a workshared project for an archive review. The copy must have no connection to the live central model, but its existing workset organization should remain available.

Which opening option is most appropriate for the archived copy?

  1. Open the live central model with Create New Local selected, and rename the resulting local file for the archive.
  2. Open the model with Detach from Central, choose to preserve worksets, and save it under a new name. (correct answer)
  3. Open the model with Detach from Central, choose to discard worksets, and recreate the worksets after saving.
  4. Open an existing local model normally, use Reload Latest, and remove the central model's network folder from the project path.
Explanation: When working with workshared Revit projects, the key concept to understand is the difference between local files (working copies tied to a central model) and detached copies (fully independent files with no central model relationship). Archive scenarios always require a clean break from the live central model. Detaching from Central is the correct workflow here. When you open a workshared model and select Detach from Central, Revit severs the link to the central file entirely. Choosing to preserve worksets (as in option B) keeps all the workset structure intact — teams, phases, or discipline separations remain organized exactly as they were. Saving under a new name then produces a standalone archive file with no path back to the live project. This satisfies both requirements: no central connection and retained workset organization. Option A fails because creating a new local file explicitly maintains the central model relationship — that's the opposite of what an archive needs. Renaming the file doesn't remove the embedded central model path; Revit still knows where the central model lives. Option C technically detaches the model correctly but then discards the worksets, destroying the organizational structure the BIM manager specifically needs to preserve. Recreating worksets manually afterward is unnecessary extra work and risks inconsistency. Option D is fundamentally flawed — local models opened normally remain tethered to the central model through their saved path. Removing a network folder doesn't cleanly sever the Revit relationship; it simply breaks the sync, which can cause errors rather than producing a clean archive. Study tip: On Revit exam questions involving archiving or isolation, look for "Detach from Central" paired with "preserve worksets" as the signal combination for a safe, complete archive workflow.

Question 8

A damaged central model is replaced by a restored backup that has been verified and saved as the project's central model. Several users still have local models that were created from the damaged version.

What should the BIM manager instruct those users to do before resuming work?

  1. Open the existing local models and synchronize them immediately so their changes overwrite differences in the restored central model.
  2. Rename the restored central model to match each local model temporarily, then use Reload Latest to repair the associations.
  3. Set aside the existing local models and create new local models from the verified, restored central model at its current location. (correct answer)
  4. Detach each existing local model, preserve its worksets, and use all detached files concurrently alongside the restored central model.
Explanation: When working with Revit worksharing, you need to understand the relationship between central models and local models. A local model is essentially a copy tied to a specific central model — it knows where "home" is. When that central model is replaced (even with a verified backup), any local models created from the damaged version are still pointing to the wrong source, making them unreliable starting points. The safest and most correct approach is C: users should discard their old local models and create fresh ones from the restored central model. This ensures everyone is working from a clean, verified baseline with no corrupted data inheritance. Creating a new local model from the restored central is straightforward — simply open the central model with the option to create a new local copy. Option A is dangerous because synchronizing from a local model tied to the damaged version could reintroduce corrupted elements into the restored central, defeating the entire recovery effort. Option B describes a non-existent workflow — Revit doesn't use filename matching to repair central-local associations, and "Reload Latest" doesn't re-link a local model to a different central file. Option D introduces significant risk by running detached files concurrently with the restored central model; detaching a local model severs its worksharing connection entirely, and using multiple detached files alongside the central creates unmanageable version conflicts. A useful rule of thumb for worksharing questions: whenever the central model changes fundamentally (replacement, restoration, or path change), treat all existing local models as orphaned and start fresh. Never assume a local model from a compromised source is safe to sync.

Question 9

A BIM coordinator creates an Interiors workset and assigns several walls to it. No user has made the entire workset editable, and no one currently owns or has borrowed those walls. A designer claims that only members of the interiors team can now edit them.

Which statement correctly evaluates the designer's claim?

  1. The claim is correct because an element's assigned workset permanently determines which project team may modify that element.
  2. The claim is incorrect because workset assignment alone does not reserve elements; editing is controlled through ownership and borrowing. (correct answer)
  3. The claim is correct because creating a named workset automatically grants its creator exclusive ownership of every assigned element.
  4. The claim is incorrect because walls cannot participate in element borrowing and must remain editable by every user simultaneously.
Explanation: When you see a question about worksets and editing rights in Revit, the key is distinguishing between two separate concepts: workset assignment and element ownership. These are often confused, but they control completely different things. Workset assignment is simply an organizational label — it groups elements logically so teams can filter visibility and manage linked files more efficiently. It does not create any access restriction. Editing rights in a workshared Revit model are governed by the ownership and borrowing system: a user gains the right to edit an element either by making its workset editable (claiming ownership of all elements in it) or by borrowing individual elements. Until one of those actions occurs, any team member with access to the central model can request and edit any element, regardless of which workset it belongs to. Since the scenario states no one owns or has borrowed those walls, they remain available to any user — making B the correct evaluation. A is wrong because workset assignment carries no permanent access restriction. It's a classification tool, not a permission system. C introduces a fictional rule — creating a workset does not automatically grant its creator ownership of assigned elements; that would require explicitly making the workset editable. D is wrong in a different direction: walls absolutely can participate in element borrowing; this answer invents a limitation that doesn't exist in Revit. As a study tip, remember the phrase: assignment organizes, ownership restricts. On the exam, any answer that conflates workset membership with editing permissions is almost certainly a trap.

Question 10

A user has an established local model. During a temporary network outage, the central model becomes unavailable, but the user can still open the local file and access elements that are currently editable by that user.

What is the most accurate description of how the user should proceed?

  1. Continue working and use Save As to convert the local model automatically into a replacement central model during the outage.
  2. Stop all work because a local model cannot save any changes while its associated central model is unavailable.
  3. Continue working, because Revit will automatically synchronize each local change when the central model becomes available again.
  4. Continue working where permitted and save locally, but wait for central access before attempting to synchronize the changes. (correct answer)
Explanation: When working in a Revit worksharing environment, it helps to understand the relationship between local files and the central model. A local file is your personal working copy — it stores your edits independently until you choose to synchronize with the central model. The central model is the shared hub, but it is not required for every action you take locally. This distinction is exactly what answer D captures correctly. During a network outage, you can continue editing any elements you already have checked out (owned), because those edits live in your local file. You can save your local file at any time to preserve your progress. However, you must wait until the central model is accessible again before running Synchronize with Central — that operation requires a live connection to the central file to exchange ownership and merge changes. Answer A is wrong because Save As does not automatically convert a local file into a new central model in any meaningful recovery sense during an outage — and attempting to create an impromptu replacement central model would create serious coordination problems for the rest of the team. Answer B overstates the limitation. You are not completely blocked from working; you simply cannot synchronize. Your local file remains open and editable for elements you own, and local saves still function normally. Answer C is wrong because Revit does not automatically queue and push changes to the central model once the network returns. Synchronization is always a manual, user-initiated action. Remember this rule of thumb: local saves protect your work; Synchronize with Central shares it. Network outages block sharing, not working.