Autodesk Revit Quiz: Worksets
10 questions · exam conditions
0:00
WorksetsQuestion 1 of 10

A workshared project currently has Interiors as the active workset. Several existing walls are assigned to Shell. Before placing additional walls, the user changes the active workset to Core, but does not modify the existing selection.

After the additional walls are placed, how will the workset assignments be distributed?

Both the existing and additional walls will be assigned to Core because changing the active workset updates wall assignments.
Both the existing and additional walls will remain assigned to Shell because new walls inherit the assignment of nearby walls.
The existing walls will remain on Shell, while the additional walls will be assigned to Core as they are created.
The existing walls will move to Interiors, while the additional walls will remain unassigned until synchronization.
← Back to quizzes

Autodesk Revit Quiz

Autodesk Revit Quiz: Worksets

Practice Worksets 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 Worksets, 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 workshared project currently has Interiors as the active workset. Several existing walls are assigned to Shell. Before placing additional walls, the user changes the active workset to Core, but does not modify the existing selection.

After the additional walls are placed, how will the workset assignments be distributed?

  1. Both the existing and additional walls will be assigned to Core because changing the active workset updates wall assignments.
  2. Both the existing and additional walls will remain assigned to Shell because new walls inherit the assignment of nearby walls.
  3. The existing walls will remain on Shell, while the additional walls will be assigned to Core as they are created. (correct answer)
  4. The existing walls will move to Interiors, while the additional walls will remain unassigned until synchronization.
Explanation: Whenever you see a question about worksharing in Revit, focus on one core principle: the active workset controls newly created elements, but it never retroactively reassigns existing ones. When you change the active workset — say, from Interiors to Core — you are simply telling Revit, "anything I create from this moment forward belongs to Core." Elements already placed in the model keep whatever workset they were assigned to at the time of creation. No automatic reassignment happens behind the scenes. This means the existing walls sitting on Shell stay on Shell, and your newly placed walls land on Core. That's exactly what answer C describes, making it correct. Answer A is wrong because it assumes changing the active workset acts like a batch reassignment tool — it doesn't. The active workset is a placement setting, not an editing command. Answer B incorrectly suggests that new walls inherit their workset from nearby geometry. Revit has no such proximity-based inheritance rule; the active workset alone determines where a new element is assigned. Answer D introduces two false ideas: existing walls don't migrate to the previously active workset (Interiors), and new elements are never left "unassigned" — they always receive the current active workset at the moment of placement. A useful tip for the exam: think of the active workset like a "stamp" you're using while drafting. Switching stamps changes only what gets stamped going forward — everything already on the page keeps its original mark. If you ever want to move existing elements to a different workset, you must select them and change their Workset property manually in the Properties palette.

Question 2

Maya needs to modify a door on the Interiors workset. The workset is not editable by Maya, but no user owns the workset and no user has borrowed the door. The project permits element borrowing.

What is the most appropriate way for Maya to make the change while minimizing unnecessary ownership?

  1. Make the entire Interiors workset editable before modifying the door, thereby reserving every element on that workset.
  2. Modify the door and allow Revit to borrow that individual element, because neither the door nor its workset is owned. (correct answer)
  3. Move the door to Maya's active workset before modifying it, because elements on noneditable worksets cannot be borrowed.
  4. Wait until every project workset is relinquished, because borrowing is unavailable while any workset remains editable.
Explanation: Whenever you see a Revit worksharing question about making edits, focus on the principle of minimum necessary ownership — Revit is designed to let you borrow individual elements rather than locking down entire worksets unless you truly need to. In this scenario, the door is unowned, the workset is unowned, and the project allows element borrowing. This is the ideal situation for element borrowing: Revit will automatically request ownership of just that one door when Maya attempts to modify it, without requiring her to claim the entire Interiors workset. That's exactly what makes B correct — it's the most targeted, least disruptive approach, and Revit handles the borrowing request seamlessly in the background. A is tempting but represents a common anti-pattern. Making the entire workset editable reserves every element on it, blocking teammates from editing anything else on that workset. This is unnecessary when only one door needs to change. C is based on a misconception — elements on non-editable worksets can be borrowed individually; you do not need to move the element to your active workset to modify it. The active workset controls where newly placed elements land, not whether existing elements on other worksets are editable. D is flatly false — element borrowing coexists with other worksets being editable. Borrowing and workset editability are independent mechanisms. As a study tip, remember: borrow the element, not the workset whenever possible. Questions that offer "make the whole workset editable" as an option are almost always testing whether you recognize that as unnecessary over-ownership.

Question 3

A host project contains one instance of a large Revit link. The link instance is assigned to a user-created workset named Coordination Links. A team member does not need the link during an editing session and wants to avoid loading it when opening the host model.

Which action best uses the host workset structure to improve opening performance?

  1. Open the host model with Coordination Links closed so that the link instance on that workset is not loaded for the session. (correct answer)
  2. Open Coordination Links and hide the link category in the active view so that the linked file is excluded from memory.
  3. Make a different workset active before opening the host model so that Revit bypasses every link on inactive worksets.
  4. Make Coordination Links noneditable after opening the host model so that the linked file is automatically unloaded.
Explanation: Whenever you see a question about Revit worksets and performance, focus on the relationship between workset visibility at open time versus after the model is loaded — these are two very different moments with very different effects. Worksets can be set to Closed when you open a host model, which tells Revit not to load the elements on that workset into memory at all. This is the key to answer A: by opening the host model with the Coordination Links workset closed, the link instance assigned to it is never loaded into the session, directly improving open performance and reducing memory overhead. This is the intended, supported workflow for managing large linked files through workset organization. Answer B is wrong because hiding a category in a view is purely a visual setting — the linked file is still fully loaded into memory; you've just toggled its display. Hiding doesn't free any resources. Answer C reflects a common misconception. The active workset determines where new elements you create are placed — it has absolutely no effect on which worksets Revit loads when opening the model. Changing the active workset before opening does nothing to bypass other worksets. Answer D confuses editability with load state. Making a workset noneditable is a worksharing ownership action that controls who can modify elements — it does not unload or detach any linked files. As a study tip, remember the distinction: Closed workset at open time = not loaded into memory. View visibility and editability settings operate on already-loaded content and never affect what Revit loads during the open process.

Question 4

A standalone project must be converted into a file that several office users can edit concurrently on a shared network. The project has not previously used worksharing.

Which sequence establishes an appropriate workshared-model workflow?

  1. Create user-named local files first, then enable worksharing independently in each file and merge them through synchronization.
  2. Enable worksharing, organize the resulting worksets, save the model as the central model, and have users create local copies. (correct answer)
  3. Save the standalone model as a template, enable worksharing in the template, and let each user create a central model.
  4. Create design options for each user, save one ordinary project file, and use the options as substitutes for local copies.
Explanation: Whenever you see a question about setting up collaborative work in Revit, anchor your thinking to the worksharing workflow sequence: one central model lives on the network, and each user works in their own local copy that syncs back to it. Getting the order of operations right is everything here. The correct path is B. Starting from a standalone file, you first enable Worksharing (via the Collaborate tab), which automatically generates default worksets. You then organize those worksets to reflect logical divisions of the model (such as by discipline or building system), save the file to a shared network location as the central model, and finally have each team member use "Create New Local" to generate their own local copy. Edits flow from local files back to the central model through Synchronize with Central. A is built on a fundamental misunderstanding — worksharing isn't something you enable in multiple separate files and then merge. There is exactly one central model; you cannot stitch independent files together through synchronization after the fact. C confuses project templates with central models. A template (.rte) is a starting point for new projects — it carries standards and settings, not a live, shared model. Having each user create their own central model from a template defeats the entire purpose of a single shared source of truth. D conflates Design Options with worksharing. Design Options let one user explore multiple design alternatives within a single file — they are not a collaboration or file-management tool and provide no mechanism for concurrent multi-user editing. A good memory anchor: one central model, many local copies — that hierarchy never changes in Revit worksharing.

Question 5

A large central model contains separate Shell, Interiors, Site, and Furniture worksets. A structural consultant needs only the Shell and Site geometry and wants to reduce the initial memory and loading demand when creating a local copy.

Which workflow best meets the consultant's objective?

  1. Use Specify for worksets when opening the model, and open only Shell and Site before the model finishes loading. (correct answer)
  2. Open every workset, then hide Interiors and Furniture with view-specific workset visibility overrides.
  3. Open every workset, then turn off the categories used by Interiors and Furniture in the active view.
  4. Set Shell as the active workset, because only elements on the active workset are loaded into memory.
Explanation: Whenever you see a question about worksets and performance in Revit, the key concept is understanding when elements are loaded into memory — not just whether they're visible on screen. When you open a Revit central model (or create a local copy), Revit gives you the option to Specify worksets before the file fully loads. This is the critical window: choosing which worksets to open means Revit only reads and loads those elements into RAM. The consultant who selects only Shell and Site through this dialog achieves exactly what the question asks — reduced memory footprint and faster load times from the start. This makes A the correct workflow. B is a common trap. Opening every workset first loads all geometry into memory regardless of what you later hide. Workset visibility overrides in views are purely a display setting — they don't unload elements from RAM. The memory demand is already done. C has the same fundamental flaw as B. Turning off categories in a view changes what you see, not what's loaded. Interiors and Furniture elements remain fully resident in memory; you've only suppressed their display. D reflects a misconception about what the active workset does. Setting a workset as active only determines which workset newly created elements are assigned to — it has absolutely no effect on which worksets are opened or loaded into memory. The study tip here: in Revit, visibility ≠ memory. Hiding elements in a view never reduces RAM usage. Only the Specify worksets option at open time, or later using the Close Worksets command, actually controls what's loaded.

Question 6

The team decides that the workset named West Wing should instead be named Renovation Zone. The workset contains many elements and has view-specific visibility overrides in several coordination views.

What is the expected result of renaming the workset in the Worksets dialog?

  1. Revit creates a new empty Renovation Zone workset, while the existing elements remain assigned to West Wing.
  2. Revit reassigns the elements to the active workset and removes the existing view-specific visibility overrides.
  3. Revit requires every element to be manually reassigned because workset names are stored independently on each element.
  4. The existing workset receives the new name, while its elements and workset-based view overrides remain associated with it. (correct answer)
Explanation: When working with worksets in Revit, it helps to think of a workset name as simply a label attached to a persistent internal object — not as a fundamental identifier that elements track independently. Renaming a workset in the Worksets dialog is essentially a metadata update: Revit changes what the workset is called, but everything associated with it — elements, visibility settings, and view overrides — remains linked through the workset's internal ID, not its display name. This makes D correct. When you rename West Wing to Renovation Zone, Revit updates the name in place. All elements already assigned to that workset stay assigned, and any view-specific visibility overrides configured for that workset in coordination views continue to function without interruption. No manual reassignment or reconfiguration is required. A is wrong because Revit does not create a parallel empty workset and strand the old elements behind. There is no duplication — the existing workset simply receives a new name. B describes behavior that doesn't exist; renaming a workset has no effect on element assignments or view overrides, and Revit certainly doesn't reset overrides as a side effect of a name change. C reflects a misunderstanding of how Revit stores workset membership. Elements don't hold an independent copy of the workset name — they reference the workset object itself, so a rename propagates automatically. A good study tip: on Revit exam questions involving worksets, ask yourself whether Revit is tracking something by name or by internal reference. Most workset associations use internal references, which is why renaming, moving, or reorganizing worksets rarely breaks existing relationships.

Question 7

A temporary Existing Survey workset contains model elements that must remain in the project. The team now wants to eliminate that workset and place its elements on Site. Existing Survey is not active, and the necessary ownership is available.

Which procedure should be used?

  1. Rename Existing Survey to Site, which automatically combines it with the existing Site workset and retains all elements.
  2. Delete Existing Survey in the Worksets dialog and choose the option to move its elements to the Site workset. (correct answer)
  3. Close Existing Survey, synchronize with central, and then reopen Site so that Revit transfers the hidden elements.
  4. Make Site active and purge Existing Survey, which reassigns the remaining elements to the active workset.
Explanation: Workset management in Revit requires understanding how elements are assigned to worksets and what tools actually control that assignment. When you need to move elements from one workset to another and then eliminate the source workset, the key is using the Worksets dialog's delete function, which gives you a migration option for the orphaned elements. When you delete a workset in Revit, the software prompts you to choose a destination workset for all elements currently assigned to it. This is the correct and intended workflow — select Existing Survey for deletion, then direct its elements to Site when prompted. That's exactly what option B describes, making it the right procedure. Option A is tempting but fundamentally wrong: renaming a workset does not merge it with another workset of the same name. Revit treats workset names as labels only; two worksets cannot occupy the same identity, and renaming creates a conflict rather than a merge. Option C is a fabricated workflow — closing and reopening worksets controls their visibility, not element ownership or assignment. Elements don't "transfer" between worksets through visibility toggling. Option D misrepresents the Purge function entirely; purging in Revit removes unused families, materials, and view types — it has no mechanism for reassigning workset elements to an active workset. Making a workset active only determines where new elements are placed. A useful pattern to remember: whenever a Revit question involves eliminating a workset while preserving its contents, think delete with migration. The delete workflow in the Worksets dialog is the only native tool that combines workset removal with controlled element reassignment in a single operation.

Question 8

A project manager proposes creating a separate workset for nearly every model category so that plans can be controlled by opening and closing category-specific worksets. The project already uses view templates and filters effectively.

Which alternative is the most appropriate strategy for model organization and performance?

  1. Create the category-specific worksets because workset closure should replace category visibility controls in every documentation view.
  2. Create a workset for each individual user because permanent user-based ownership provides the greatest editing flexibility.
  3. Use a limited set of logical worksets for collaboration or selective loading, and retain view templates and filters for display control. (correct answer)
  4. Use only the default workset because additional worksets cannot improve selective loading or coordination in a large project.
Explanation: When working with Revit worksets, it helps to understand their primary purpose: enabling collaborative multi-user editing and allowing selective loading of portions of a model. Worksets are not designed to replace visibility controls — that distinction is the heart of this question. A well-structured workset strategy uses a small number of logical groupings (site, shell, interiors, MEP, etc.) so team members can borrow elements efficiently and so linked models or large files can be partially loaded to improve performance. Since the project already uses view templates and filters effectively, those tools should continue handling display control — they're purpose-built for it. Option C is correct because it keeps worksets focused on collaboration and selective loading, while preserving the existing, appropriate tools for category visibility. Option A is a classic trap: workset closure can hide geometry, but using it as your primary visibility control method is unpredictable, slow to manage, and breaks the intended workflow. It's a workaround, not a strategy. Option B misunderstands workset ownership — Revit worksets are not meant to be permanently assigned per user. Ownership is dynamic; locking elements indefinitely to individuals creates bottlenecks and defeats collaborative flexibility. Option D swings too far in the opposite direction. The default workset alone cannot support selective loading or meaningful team coordination on large projects — additional logical worksets genuinely improve both. A useful rule of thumb for the exam: worksets = collaboration and loading; filters and view templates = display control. When you see a question mixing these concepts, ask yourself which tool is being applied to the right job.

Question 9

Before leaving for the day, Leon has borrowed several individual elements and owns two user-created worksets. He has already saved changes locally. Other team members need immediate access to everything he owns.

Which action most completely updates the central model and releases Leon's ownership?

  1. Save the local model again and close Revit, relying on the application to release all ownership automatically.
  2. Reload Latest and close the owned worksets, because a closed workset is automatically relinquished to the team.
  3. Synchronize with Central and relinquish all of his borrowed elements and owned worksets during that workflow. (correct answer)
  4. Detach the local model from central and save it, because detaching clears Leon's ownership in the original central model.
Explanation: When working in a Revit worksharing environment, you need to understand the difference between ownership and visibility. Borrowing an element or owning a workset means you hold an exclusive lock on that content — no one else can edit it until you explicitly release it. The question here tests whether you know which single workflow both pushes Leon's changes to the central model and surrenders his ownership of all locked content. Synchronize with Central (SWC) is that workflow. During SWC, Revit prompts you with a dialog where you can choose to relinquish borrowed elements, user-created worksets, and project standards worksets individually or all at once. By checking all of those options, Leon accomplishes both goals simultaneously: his local changes are written to the central model, and his locks are released so teammates can immediately access that content. This makes C the correct answer. A is wrong because simply saving locally and closing Revit does not automatically push changes to the central model or release ownership — a local save only updates Leon's own .rvt file, leaving the central model untouched and the locks intact. B is wrong because closing a workset in the Worksets dialog only makes that workset inactive (unloaded from view), not relinquished. Ownership is a separate concept from a workset's open/closed visibility state. D is wrong because detaching a local model severs its relationship with central entirely. It does not update or release anything in the original central model — it simply creates an independent copy. As a study tip, remember that in Revit worksharing, only Synchronize with Central moves data bidirectionally and offers relinquishment options — saving locally or closing worksets never releases ownership.

Question 10

When the Furniture workset was created, Visible in all views was cleared. A coordination view uses a view template that explicitly sets the Furniture workset to Show. Furniture categories, phases, and filters do not otherwise hide the elements.

What will happen to furniture elements in the coordination view?

  1. They will remain hidden because the workset's global visibility setting cannot be overridden by a view template.
  2. They will appear only after Furniture is made the active workset for the user opening the coordination view.
  3. They will remain hidden until the Furniture workset is made editable, even if the view template specifies Show.
  4. They will be visible because the view template's explicit Show setting overrides the workset's global default. (correct answer)
Explanation: Whenever you see a Revit question involving workset visibility, keep a clear hierarchy in mind: there is a global default (set when the workset is created or modified in the Worksets dialog), and then there are per-view overrides that can be set explicitly in Visibility/Graphics or enforced through a view template. These two levels are independent, and the per-view setting always wins when it is explicitly defined. When the Furniture workset was created with Visible in all views cleared, that simply establishes the global default — it tells Revit to hide the workset in views that haven't been given an explicit instruction. A view template that explicitly sets the workset to Show is exactly that kind of explicit instruction. Because the coordination view's template directly overrides the default with a "Show" command, the furniture elements will be visible. Answer D is correct for this reason. Answer A is wrong because it reverses the actual hierarchy — per-view explicit settings do override the global default; that is precisely what view-level controls are designed for. Answer B introduces the concept of the active workset, which governs only which workset newly created elements are placed on; it has nothing to do with visibility control for existing elements. Answer C confuses editability with visibility — a workset being editable (checked out by a user) is a worksharing ownership concept, completely separate from whether elements display in a view. A good rule of thumb: in Revit, explicit beats default. Any time a view or view template makes a direct Show/Hide decision, it overrides the workset's global visibility setting.