Autodesk Revit Quiz: Ownership And Borrowing
10 questions · exam conditions
0:00
Ownership And BorrowingQuestion 1 of 10

Maya has made the Interiors workset editable. She is modifying several casework elements. Luis needs to edit one unrelated partition wall on the same workset, but Revit reports that the wall is not editable because Maya owns the workset.

Which workflow best allows both users to continue while minimizing future ownership collisions?

Maya relinquishes the Interiors workset, and both users borrow only the individual elements they need.
Maya keeps the Interiors workset editable and grants Luis ownership of the partition wall only.
Luis makes Interiors the active workset, and Maya continues owning it while he edits the wall.
Luis reloads the latest central changes, which releases Maya's ownership of the partition wall.
← Back to quizzes

Autodesk Revit Quiz

Autodesk Revit Quiz: Ownership And Borrowing

Practice Ownership And Borrowing 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 Ownership And Borrowing, 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

Maya has made the Interiors workset editable. She is modifying several casework elements. Luis needs to edit one unrelated partition wall on the same workset, but Revit reports that the wall is not editable because Maya owns the workset.

Which workflow best allows both users to continue while minimizing future ownership collisions?

  1. Maya relinquishes the Interiors workset, and both users borrow only the individual elements they need. (correct answer)
  2. Maya keeps the Interiors workset editable and grants Luis ownership of the partition wall only.
  3. Luis makes Interiors the active workset, and Maya continues owning it while he edits the wall.
  4. Luis reloads the latest central changes, which releases Maya's ownership of the partition wall.
Explanation: Whenever you see a Revit worksharing question involving ownership conflicts, focus on the difference between workset ownership and element borrowing. Owning an entire workset locks every element in it — no one else can edit anything there. Borrowing, by contrast, lets individual users check out only the specific elements they need, leaving everything else available. That distinction is exactly what makes A the right answer. When Maya relinquishes the Interiors workset, she releases the blanket lock on all its elements. Both she and Luis can then borrow only the specific elements each person needs — Maya her casework, Luis his partition wall. This keeps them productive simultaneously and reduces the chance of future conflicts because no one holds a wide lock unnecessarily. B is a trap because Revit does not have a feature that lets one user "grant" ownership of a specific element to another while retaining workset ownership themselves. Workset ownership is all-or-nothing; element borrowing is what enables granular control, and it must be requested, not delegated. C misunderstands what "active workset" means. Setting a workset as active simply determines where new elements are placed — it has no effect on ownership or editing rights for existing elements. Luis still cannot edit the wall Maya owns. D is incorrect because reloading central does not release another user's ownership. Ownership is only relinquished when the owning user explicitly does so (via Relinquish All Mine or similar) and syncs to central. Study tip: Remember the hierarchy — workset ownership beats element borrowing. When conflicts arise, the cleanest fix is always to narrow the lock to just what each user actually needs.

Question 2

Nina cannot edit an existing ceiling because another user owns it. She changes her active workset to the workset containing that ceiling and attempts the edit again.

What effect does changing the active workset have on this ownership conflict?

  1. It requests ownership of every existing element assigned to the newly active workset.
  2. It controls the workset assignment of new elements but does not release or override the ceiling's ownership. (correct answer)
  3. It transfers the ceiling to Nina's previous active workset and makes the ceiling editable.
  4. It makes the workset editable for Nina but leaves the ceiling borrowed by the other user.
Explanation: Worksharing in Revit separates two distinct concepts that this question deliberately conflates: workset assignment and element ownership. When you see a question mixing these ideas, pause and ask yourself: "Is this about which workset something belongs to, or about who has permission to edit it?" The active workset in Revit controls only one thing — the workset that newly created elements will be assigned to. It has absolutely no effect on elements that already exist. So when Nina switches her active workset, she is simply telling Revit, "put my next wall, ceiling, or component into this workset." That's it. The ownership conflict — another user having borrowed the ceiling — remains completely unchanged. Answer B captures this precisely: the active workset governs new element placement, not existing element ownership. Answer A is wrong because switching the active workset never triggers an automatic ownership request for existing elements in that workset. Ownership must be explicitly requested through "Make Worksets Editable" or by attempting to edit individual elements. Answer C describes a behavior that doesn't exist at all — the active workset doesn't reassign or transfer existing elements, nor does switching it make borrowed elements editable. Answer D is partially plausible but still incorrect; making a workset "editable for Nina" implies she gains control over its contents, which doesn't happen simply by activating it. The key study tip here: in Revit Worksharing, ownership is per-element, not per-workset. Another user borrowing a ceiling means only that specific ceiling is locked — not every element in the workset. Don't let workset-level actions fool you into thinking they resolve element-level borrowing conflicts.

Question 3

Chen needs to edit a column currently borrowed by Elena. Chen submits an editing request while Elena still has unsynchronized modifications to that column.

Which sequence best protects Elena's work and gives Chen access to the current element?

  1. Chen reloads latest and edits the column while Elena synchronizes her version afterward.
  2. Elena completes and synchronizes her changes, then relinquishes or grants the request before Chen retries. (correct answer)
  3. Elena grants the request immediately, and both users synchronize their column changes in sequence.
  4. Chen makes the column's workset editable, forcing Elena's borrowed-element changes into the central model.
Explanation: When working in a Revit worksharing environment, borrowed elements are exclusively "owned" by the user who checked them out. No other user can edit that element until ownership is properly released back to the central model. Questions like this test whether you understand the correct handoff workflow between collaborators. The safest sequence is the one in B: Elena finishes her modifications, synchronizes with the central model (which writes her changes into the shared file), and then either relinquishes the element or explicitly grants Chen's pending request. Once Elena has synced, her work is permanently saved in the central model. Chen can then reload latest and begin editing the column with full confidence that nothing will be lost or overwritten. A is dangerous because Chen cannot actually edit a borrowed element while Elena still owns it — Revit won't allow it. Even if a workaround existed, editing before Elena synchronizes risks a conflict where her unsynchronized changes are lost or create an irresolvable merge problem. C sounds cooperative, but granting the request before Elena synchronizes means her local changes are not yet in the central model. If Chen takes ownership and syncs first, Elena's unsaved modifications could be orphaned or overwritten when she eventually tries to sync. D misrepresents how worksets function. Making a workset editable controls the workset's ownership, not individual borrowed elements. You cannot forcibly push another user's unsynchronized borrowed-element changes into the central model this way — it's not a valid Revit operation and would likely cause errors. Study tip: In worksharing questions, always ask: "Has the current owner synced first?" If not, no safe handoff has occurred.

Question 4

Two team members create local models from the same central model while their Revit installations use the same user name. The team begins seeing ownership messages that appear to attribute both users' changes to one person.

What is the most appropriate corrective action before they continue editing?

  1. Assign each person a unique Revit user name and create fresh local models from the central model. (correct answer)
  2. Give each person a different active workset while retaining the shared Revit user name.
  3. Rename each local file differently and continue using the same Revit user name for ownership.
  4. Rename the central model so Revit can distinguish ownership from the two existing local models.
Explanation: When working with Worksharing in Revit, the central model tracks element ownership using each user's Revit username as the identifier — not the local file name or the workset assignment. This means the username is the backbone of the entire permission and ownership system. Whenever you see a scenario involving confused or merged ownership in a workshared environment, your first instinct should be to examine whether usernames are unique. Here, both users share the same username, so Revit literally cannot tell them apart. Every element they borrow or check out gets attributed to a single identity, causing ownership conflicts and misleading messages. The fix is straightforward: give each person a distinct username in Revit's options (Application Menu → Options → General), then create new local models from the central file. This resets the user association cleanly, which is exactly what option A describes — making it the correct answer. Option B is wrong because workset assignments control which workset is active for new elements, not who "owns" borrowed elements. Sharing a username still means Revit cannot distinguish between the two people, regardless of workset. Option C is a common trap — renaming the local files feels like differentiation, but Revit's ownership system ignores the local file name entirely. The username embedded in the model data is what matters. Option D misunderstands the problem. Renaming the central model does nothing to resolve the username conflict; it would also break the existing local models' connection to it. Your study tip: on Worksharing questions, always trace problems back to the username first — it controls permissions, ownership, and synchronization identity throughout the entire collaborative workflow.

Question 5

Fatima opens a workshared model, selects several structural walls, and reads their properties without changing any values. She does not make their workset editable. At the same time, Noah attempts to modify one of those walls, and no other user owns it.

What should happen when Noah begins the modification?

  1. Noah should be blocked because selecting an element reserves it for the duration of Fatima's session.
  2. Noah should be blocked until Fatima synchronizes, because reading properties creates a pending central transaction.
  3. Noah should be able to borrow the wall because selecting and inspecting it does not acquire ownership. (correct answer)
  4. Noah should receive the wall only after Fatima changes to a different active workset or closes the view.
Explanation: When working with workshared Revit models, you need to understand the difference between viewing/selecting an element and owning it. Revit's borrowing system is designed to be non-blocking for read-only actions — ownership is only acquired when a user actually begins editing an element, not simply by clicking on it or reading its properties. This is exactly why C is correct. Fatima selecting walls and inspecting their properties in the Properties palette does not place a borrow request or claim ownership. Because no one owns those walls, Noah can freely borrow one the moment he initiates a change. Revit will automatically request borrowing rights from the central model at that point. A is wrong because selecting an element in Revit is a read-only action — it does not "reserve" or lock the element for your session. Revit would be nearly unusable if casual selection blocked other collaborators. B is incorrect because reading properties generates no pending transaction with the central model; a transaction only occurs when you actually modify something and sync. Fatima's inspection leaves no footprint in the central file. D is incorrect because workset editability and active worksets are separate concepts from element borrowing — Noah's ability to borrow a specific wall has nothing to do with which workset Fatima currently has active or which view she is in. A helpful rule of thumb: in Revit worksharing, ownership follows editing, not viewing. If a question describes someone only reading or selecting without making changes, assume no ownership has been acquired and other users remain unblocked.

Question 6

Owen borrowed several doors, modified them, and synchronized with the central model. During synchronization, he cleared the Borrowed Elements relinquishment option. Priya then attempts to edit one of the doors and is still denied permission.

What most directly explains the denial, and what should Owen do?

  1. Synchronization published the changes but retained the borrowed elements; Owen must relinquish those elements. (correct answer)
  2. Synchronization converted the doors into workset-owned elements; Owen must relinquish the complete workset.
  3. Priya's local model predates the door changes; she only needs to use Reload Latest before editing.
  4. The doors became read-only after synchronization; Owen must reopen his local model to unlock them.
Explanation: Whenever you see a Revit worksharing question involving synchronization and element access, focus on the distinction between publishing changes and relinquishing ownership — these are two separate actions that do not automatically happen together. When Owen cleared the Borrowed Elements checkbox during synchronization, he told Revit to keep his borrower locks on those doors even after his edits were pushed to the central model. Synchronizing uploads your changes successfully, but ownership of borrowed elements is only released when you explicitly relinquish them — either by checking that option or using Relinquish All Mine. Because Owen still holds the borrow locks, Priya's request to edit the doors is blocked at the permission level, regardless of whether she has the latest version of the model. This makes A correct. B is wrong because synchronization does not convert borrowed elements into workset-owned elements. Borrowing and workset ownership are distinct states; clearing the borrow option wouldn't trigger a workset-level ownership transfer. C is a tempting distractor because Reload Latest is often the fix when Priya can't see updated content — but here the problem isn't a stale model, it's an active ownership lock. Reloading won't remove Owen's borrow lock. D is incorrect because elements don't become generically "read-only" after sync in a way that's solved by reopening a local model. That's not a real Revit worksharing behavior. As a study habit, remember: in Revit worksharing, synchronizing ≠ relinquishing. Always check which relinquishment boxes are selected before clicking Synchronize with Central.

Question 7

Sam is blocked from editing a stair owned by Riley. Sam chooses Reload Latest, receives Riley's most recently synchronized stair geometry, and then attempts the edit again. Riley has not relinquished the stair.

What should Sam expect after Reload Latest?

  1. The stair should become editable because receiving Riley's changes transfers the borrowing status to Sam.
  2. The stair should move to a shared state in which both users can modify separate stair components.
  3. The stair should become editable only if Sam's active workset matches the stair's assigned workset.
  4. The stair should remain unavailable because Reload Latest updates data without relinquishing Riley's ownership. (correct answer)
Explanation: When working in a Revit worksharing environment, it helps to clearly separate two distinct operations: syncing/viewing updated data and relinquishing element ownership. Questions like this test whether you understand that those are completely independent actions. Reload Latest pulls the most recently synchronized version of the central model into your local file, so you can see changes your teammates have made. Critically, it does nothing to the borrowing status of elements. If Riley has checked out the stair — meaning Riley's local file holds an active borrow on that element — Riley must explicitly relinquish it (by syncing with central and releasing it, or using Relinquish All Mine). Until that happens, the stair stays locked to Riley. Sam receiving updated geometry doesn't transfer or dissolve that lock. So D is correct: the stair remains unavailable because ownership and data synchronization are separate concerns. Choice A misunderstands the borrowing model — receiving someone's changes never transfers ownership to you; ownership only moves when the current owner relinquishes it. Choice B describes a fictional "shared editing" mode; Revit's worksharing model grants exclusive element ownership to one user at a time, not simultaneous co-editing of the same element. Choice C introduces workset assignment as the deciding factor, but while worksets organize elements, they don't override element-level borrowing — even if Sam's active workset matches, Riley's borrow still blocks the edit. As a study tip: on Revit worksharing questions, always ask yourself who currently owns the element and have they relinquished it? Reload Latest, workset switching, and local saves are all distractors that don't affect element borrowing status.

Question 8

Taylor owns one wall instance because she is moving it. Morgan needs to modify a type parameter of the wall type used by that wall and many other walls. The wall type itself is currently available.

Which ownership requirement applies to Morgan's type-level modification?

  1. Morgan must acquire every instance using the wall type before changing the type parameter.
  2. Morgan must own the project standards workset and every workset containing an affected wall instance.
  3. Morgan must acquire the wall type, while Taylor's ownership of one instance does not by itself block the type edit. (correct answer)
  4. Morgan can change the type without borrowing anything because type parameters are not workshared items.
Explanation: When working in a Revit workshared project, you need to understand the distinction between instance ownership and type ownership. Instances and types are separate borrowable elements — owning one does not grant rights over the other, and vice versa. To modify a type parameter, Revit requires that you borrow (acquire) the wall type itself. The type lives as its own element in the worksharing system, independent of any wall instances that use it. This means Morgan needs to check out the wall type — and as long as no one else currently owns that type, she can do so freely. The passage confirms the wall type is currently available, so Morgan can acquire it and make her modification. Taylor's ownership of one wall instance is irrelevant to type-level edits; she owns that geometric object, not the type definition. This makes C the correct answer. A is wrong because Morgan does not need to own every instance using the type. Type parameters are stored on the type element, not distributed across instances — changing the type propagates automatically without requiring instance ownership. B is wrong because editing a type does not require owning the Project Standards workset or every workset containing affected instances. Revit's borrowing model handles type changes at the type-element level, not by locking entire worksets. D is wrong in the opposite direction — it understates the requirement. Types are workshared elements and do require borrowing. You cannot edit them without acquiring ownership. Study tip: Remember the rule: instances and types are independent borrowable elements. When a question mixes instance ownership with type modification, always ask yourself which element actually stores the parameter being changed.

Question 9

Devon has unsynchronized changes to borrowed elements when his workstation loses its network connection. A colleague urgently needs those same elements, but Devon's local model and changes are still intact.

Which recovery workflow best avoids both ownership conflicts and loss of Devon's work?

  1. The colleague reloads latest repeatedly until the central model times out Devon's ownership of the borrowed elements.
  2. The colleague changes to Devon's user name, creates another local model, and relinquishes Devon's elements immediately.
  3. Devon deletes his local model so the central model automatically releases his ownership and preserves his changes.
  4. Devon reconnects using the same local model and user identity, synchronizes, and relinquishes before the colleague edits. (correct answer)
Explanation: When Devon's workstation loses its network connection, his borrowed element ownership is still registered in the central model — and his local file still contains his unsaved changes. Questions like this test whether you understand how Revit's worksharing system handles ownership, synchronization, and recovery without corrupting the project or losing work. The safest path is D: Devon reconnects using the same local model and the same Revit user identity he originally used. Because ownership in the central model is tied to his username, reconnecting with that same identity lets him pick up exactly where he left off. He can then synchronize with central, which both uploads his changes and formally relinquishes his borrowed elements — freeing the colleague to edit them cleanly and without conflict. A is flawed because repeatedly reloading latest does not force ownership release; it simply refreshes what is visible. There is no automatic timeout mechanism triggered this way, and the colleague still cannot edit Devon's elements. B is a serious mistake. Impersonating another user's credentials violates Revit worksharing protocol and can corrupt ownership records in the central model. It also risks overwriting Devon's changes entirely, since a new local file would not contain his edits. C is wrong because deleting a local model does not release ownership in the central model — it simply orphans the borrowed elements indefinitely. Devon's changes would also be permanently lost with the file. Study tip: In worksharing scenarios, always remember that ownership is resolved through synchronization, not by deleting files or switching usernames. If the original local file and username are intact, reconnecting and syncing is almost always the correct recovery path.

Question 10

Avery has borrowed a floor plan view after changing its crop region. Jordan opens the same view and needs to move a model wall. Neither the wall nor its model workset is owned by Avery or another user.

How does Avery's ownership of the view affect Jordan's proposed wall edit?

  1. Jordan cannot edit any model element displayed in the view until Avery relinquishes the view.
  2. Jordan can borrow the wall because ownership of the view is separate from ownership of the model element. (correct answer)
  3. Jordan can move the wall only after making the view's workset and the wall's workset editable.
  4. Jordan automatically receives ownership of the view when borrowing a model element displayed within it.
Explanation: When working with Revit's worksharing environment, it's essential to understand that views and model elements are independently owned resources. Borrowing a view — for example, to change its crop region — does not grant ownership over any model elements that happen to appear within it. These are entirely separate borrowing transactions. In this scenario, Avery owns the floor plan view itself, but the wall and its workset are unclaimed. Because Jordan wants to edit the wall (a model element), Revit only requires that Jordan borrow the wall or its workset — not the view. The view's ownership is irrelevant to that transaction. This confirms B as correct: view ownership and model element ownership are independent, and Jordan can freely borrow the wall. A is wrong because it conflates the view with the elements displayed in it. Owning a view gives you control over view-specific properties (like the crop boundary), not over any model geometry visible through it. C introduces a misconception about how workset-based editing works — you don't need to make a view's workset editable to edit a model element; you only need to borrow the element or its own workset, and since neither is owned, Jordan can do this directly. D describes a behavior that simply doesn't exist in Revit; borrowing a model element never automatically transfers view ownership. A useful rule of thumb: in Revit worksharing, always ask what type of object is being edited — view properties, element geometry, or workset settings — because each is governed separately. Don't let the fact that elements appear inside a view trick you into thinking view ownership controls them.