Autodesk Revit Quiz: Linked Model Troubleshooting

10 questions · exam conditions

0:00

Linked Model TroubleshootingQuestion 1 of 10

A structural model is linked into an architectural project. In an architectural Level 2 plan, linked columns appear, but linked beams above the cut plane do not. The structural team's Level 2 framing plan displays the required beams correctly. The architect does not want to modify the host view range because it is already correct for architectural documentation.

Which Revit Link display configuration is the best way to show the framing as it appears in the structural team's plan?

Use By Host View and increase the host plan's top clip plane above the beams.

Use By Linked View and select the structural Level 2 framing plan.

Use Custom and change only the linked model's projection line color.

Use By Host View and change the host view discipline to Structural.

← Back to quizzes

Autodesk Revit Quiz

Autodesk Revit Quiz: Linked Model Troubleshooting

Practice Linked Model Troubleshooting 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 Linked Model Troubleshooting, 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

Which Revit Link display configuration is the best way to show the framing as it appears in the structural team's plan?

Use By Host View and increase the host plan's top clip plane above the beams.
Use By Linked View and select the structural Level 2 framing plan. (correct answer)
Use Custom and change only the linked model's projection line color.
Use By Host View and change the host view discipline to Structural.

Explanation: Whenever you see a question about displaying linked model elements that aren't visible in the host view, think about Revit Link display modes — specifically how each mode controls whose view settings govern what you see. In Revit, when a model is linked, you can control its visibility through three modes: By Host View (linked model inherits the host view's settings), By Linked View (linked model displays exactly as it appears in a chosen view from that file), or Custom (you manually override individual graphic settings). Here, the beams are missing because the architectural host view's cut plane and view range don't capture the structural framing — but the structural team's Level 2 framing plan is already configured correctly to show those beams. The cleanest solution is By Linked View, where you select the structural framing plan as the reference. Revit then renders the linked model exactly as that source view displays it, beams included, without touching the host view at all. That's why B is correct. A is wrong because it requires modifying the host view range — exactly what the architect wants to avoid, and it could disrupt architectural documentation. C is wrong because the Custom mode can control graphics like color and line weight, but it does not resolve a visibility issue caused by view range; the beams would still be cut out of the display. D is wrong because changing the host view discipline to Structural would alter the host view's behavior broadly, affecting the architectural documentation and again modifying the host view the architect wants to preserve. As a study tip: remember that By Linked View is your go-to whenever you need a linked model to reflect another team's view configuration without compromising your own host view settings.

Question 2

An architectural host and a structural model already share an established coordinate system. A user removes the structural link and then links it again using Origin to Origin. The structural model is now displaced, even though neither team's model geometry has moved.

What should the user do to restore the established coordinated position most reliably?

Remove and relink the structural model using the By Shared Coordinates positioning option. (correct answer)
Reload the structural model from its current path and preserve Origin to Origin placement.
Move the structural link manually until its project base point matches the host origin.
Relink the structural model using Center to Center and then pin the resulting instance.

Explanation: When working with linked models in Revit, positioning method is everything. Revit offers several options when linking a file — Origin to Origin, Center to Center, By Shared Coordinates, and Auto - Internal Origin. Each means something different, and confusing them is one of the most common coordination mistakes on real projects. Here's the core concept: Shared Coordinates is Revit's mechanism for remembering an agreed-upon real-world position between two models. When both teams have properly published and acquired shared coordinates, that relationship is stored. The By Shared Coordinates positioning option tells Revit to place the linked file exactly where the shared coordinate system says it should go — restoring the established relationship regardless of where each file's internal origin sits. That's why A is correct. Relinking with By Shared Coordinates reads the shared coordinate data already embedded in both files and places the structural model in its intended position. No manual adjustment needed. B is wrong because reloading preserves the current (incorrect) Origin to Origin placement — that's exactly what caused the displacement in the first place. Reloading doesn't change positioning logic. C is wrong because manually dragging a link to match origins is imprecise and error-prone. Even if you visually align base points, you're guessing rather than using the coordinate data the teams already established. D is wrong because Center to Center positions the link based on bounding box centers, which have no relationship to the shared coordinate agreement. Pinning it just locks that incorrect position in place. Your study tip: whenever a question involves restoring a previously coordinated position between linked models, By Shared Coordinates is almost always the answer — it's the only option that leverages the actual coordinate handshake between files.

Question 3

A Revit link appears in Manage Links as Loaded but is absent from every view opened by one team member. Other users can see the link in the same views. The link instance was placed on a dedicated workset, and the affected user opened the local model with that workset closed.

Which action most directly addresses the visibility problem without changing the link's placement or display overrides?

Change the link type from Attachment to Overlay and synchronize with the central model.
Reload the link from its saved location and choose Origin to Origin when prompted.
Enable the Revit Links category in every affected view's Visibility/Graphics settings.
Open the dedicated link workset through the Worksets dialog and regenerate the active view. (correct answer)

Explanation: Whenever you see a Revit visibility problem that affects only one user while others see the content normally, your first instinct should be to think about worksharing — specifically, workset visibility — rather than view settings or link configurations, since those would affect everyone equally. In a workshared model, each workset can be opened or closed independently when a user opens their local file. When a workset is closed, all objects on it are hidden from view for that user, regardless of Visibility/Graphics settings or whether the link shows as "Loaded" in Manage Links. The link appearing as Loaded simply means Revit knows where the file is — it doesn't mean the instance is visible if its hosting workset is closed. Opening the workset through the Worksets dialog restores the instance to the model for that session, and regenerating the active view refreshes what's displayed. That makes D the most direct fix. A is wrong because switching between Attachment and Overlay affects whether the link is visible when that model is itself linked into another — it has no bearing on workset-based visibility for a direct user. B is a red herring; reloading with Origin to Origin re-positions the link relative to a coordinate system, which solves placement drift, not a visibility gap caused by a closed workset. C would be valid if the Revit Links category were turned off in Visibility/Graphics, but that would affect all users equally — not just one — making it the wrong diagnosis here. As a study tip: when a Revit problem is isolated to a single user in a workshared environment, always check worksets before touching view settings or link management.

Question 4

Two instances of the same linked building model are placed in a site plan. Both instances are inside the crop region, use the same link type, and are assigned to open worksets. One instance is visible, while the other is not. Manage Links reports the source file as Loaded.

What is the most efficient first test for an instance-specific visibility override?

Edit Visibility/Graphics and enable every model category in the linked source file.
Open Manage Links and reload the shared link type from the source file's current path.
Activate Reveal Hidden Elements and check whether the missing link instance was hidden in the view. (correct answer)
Change the link type's reference setting from Overlay to Attachment for both instances.

Explanation: When two instances of the same link type behave differently in a view — one visible, one not — you're dealing with an instance-specific override rather than a type-level or file-level issue. The key diagnostic framework here is Revit's visibility hierarchy: file status → link type settings → view-level type overrides → instance-level overrides. Since both instances share the same loaded link type, the problem must live at the instance level. Reveal Hidden Elements (C) is your most efficient first test because it directly exposes whether the missing instance was manually hidden in the view using Hide in View → Elements. This is a one-click operation that immediately answers the question without changing any settings. If the instance appears highlighted in Reveal Hidden Elements mode, you've found your culprit and can unhide it instantly. Answer A is a category-level intervention — adjusting Visibility/Graphics for the linked model affects all instances of that link type in the view equally. Since the other instance is already visible, categories aren't the issue, making this unnecessary and misdirected. Answer B targets the link's loaded status, but Manage Links already confirms the file is Loaded, so reloading it addresses a problem that doesn't exist here. Answer D changes the Overlay/Attachment reference setting, which controls how the link behaves in nested hosting scenarios, not instance visibility within a single view — this is a completely unrelated setting. As a study tip, remember that in Revit troubleshooting questions, always match the scope of the problem to the scope of the fix. Instance-specific symptoms call for instance-specific diagnostics first — Reveal Hidden Elements is always your quickest instance-level check.

Question 5

An architectural link is visible in a coordination 3D view but not in one floor plan. Manage Links reports the file as Loaded, the link's workset is open, and Reveal Hidden Elements does not show the link. The floor plan has an assigned view template, and its Visibility/Graphics settings cannot be edited directly.

What is the most appropriate next step to restore the link in the floor plan without affecting unrelated views?

Edit the assigned view template and enable the link under the Revit Links category. (correct answer)
Reload the linked file from Manage Links and retain its current saved path.
Open the linked project and enable its model categories in the active floor plan.
Change the link type from Overlay to Attachment in the host project's type properties.

Explanation: When a linked file appears in some views but not others, and you can't edit Visibility/Graphics directly in that view, your first instinct should be to look at the view template. View templates override per-view settings, which is exactly why the floor plan's V/G settings are grayed out — the template is controlling them. The fix is straightforward: edit the assigned view template and ensure the linked file is checked under the Revit Links category. Once you enable it there, every view using that template will reflect the change — but views using different templates or no template remain unaffected. This is precisely what the question asks for: restoring visibility without impacting unrelated views. Option A is the correct path. Option B is a red herring. Reloading the link addresses file path or synchronization issues, but the passage already tells you the link is Loaded in Manage Links. There's no file-access problem to solve here. Option C misunderstands where visibility is controlled. You don't open the linked model to fix its visibility in the host's floor plan. Category visibility in the linked model doesn't govern whether the link appears in the host's views — that's controlled by the host's V/G settings or its view template. Option D confuses link type (Overlay vs. Attachment) with visibility. That setting governs whether a link propagates into nested host situations, not whether it appears in a specific view. A useful pattern to remember: whenever a Revit view has a locked or grayed-out V/G panel, always check the view template first. That template is almost always the root cause of display discrepancies that seem puzzling at the view level.

Question 6

A project team has linked a surveyed civil model into a new building model using Origin to Origin. The civil model is correctly located relative to the survey coordinate system. The building model has not yet established shared coordinates, and the team wants its spot coordinates and survey point relationship to use the civil model's coordinate system.

Which workflow most directly establishes the required coordinate relationship while keeping the civil model as the coordinate authority?

Select the civil link and use Acquire Coordinates to transfer its shared coordinate system to the host. (correct answer)
Select the civil link and use Publish Coordinates to replace its coordinates with those of the host.
Move the host project base point to the link and then pin the civil link instance.
Relink the civil file Center to Center and record the resulting position as a shared site.

Explanation: Whenever you see a question about shared coordinates in Revit, focus on the direction of information flow: which model is the authority, and which model is receiving the coordinate system? In this scenario, the civil model already has the correct survey coordinate system, and the building (host) model needs to adopt it. Acquire Coordinates (answer A) does exactly this — you select the linked civil file, run Acquire Coordinates, and Revit pulls the linked model's shared coordinate system into the host. After this, the host's survey point, spot coordinates, and true north orientation all reflect the civil model's system. The civil model remains unchanged, preserving it as the coordinate authority. This is the correct and most direct workflow. Answer B describes Publish Coordinates, which is the opposite direction — it pushes the host's coordinate system into the linked file, overwriting the civil model's carefully established survey data. This is exactly what you don't want here. Answer C, moving the project base point manually, doesn't establish shared coordinates at all. The project base point controls the internal origin offset, not the shared coordinate system, and this approach would require manual input of survey values rather than transferring them systematically from the civil model. Answer D, relinking Center to Center, changes only the insertion point of the link instance. It doesn't transfer any coordinate system data, and "recording the position as a shared site" is not a formal Revit workflow for establishing shared coordinates. A useful memory rule: Acquire = receive (host gets coordinates from the link); Publish = send (host gives coordinates to the link). Know this direction, and you'll consistently answer coordinate-sharing questions correctly.

Question 7

A documentation plan must show walls and doors from a linked architectural model but must not show that link's levels and grids. The host model's own levels and grids must remain visible. The link is currently displayed By Host View.

Which workflow provides the required result with the least effect on host-model graphics?

Turn off Levels and Grids globally in the host view's Annotation Categories settings.
Set the link display to Custom and disable Levels and Grids for the linked model. (correct answer)
Hide the entire link in the view and redraw the required linked walls with detail lines.
Open the linked file, delete its levels and grids, and reload it into the host model.

Explanation: When working with linked Revit models, you have granular control over what you see from each link without disturbing the host model's own settings. The key concept here is Revit Link Display Settings, which let you override a linked file's visibility on a category-by-category basis, independently from the host view's Visibility/Graphics overrides. Setting the linked model's display to Custom (option B) is exactly the right tool. In the Visibility/Graphics dialog, under the Revit Links tab, you can switch a specific link from "By Host View" to "Custom," then navigate to the Annotation Categories tab for that link and turn off Levels and Grids. This hides only those categories from the linked file while leaving walls, doors, and everything else intact — and crucially, it doesn't touch the host model's own levels and grids at all. Option A fails because disabling Levels and Grids in the host view's Annotation Categories applies globally to the entire view, which would hide the host model's own levels and grids — exactly what the plan requires you to keep visible. Option C is destructive and impractical; hiding the entire link loses walls and doors, forcing you to manually redraw geometry that already exists, which defeats the purpose of linking. Option D is the most dangerous choice: permanently deleting elements from the source file affects every project that references it, far exceeding the scope of a single view override. As a study habit, remember that link-level overrides always take precedence without harming host-model visibility — whenever a question asks you to filter linked content without side effects, Custom link display settings are your first instinct.

Question 8

A linked architectural model is correctly positioned and visible in a host coordination view during the Existing phase. In a host New Construction plan, most of the link disappears. The link is loaded, its categories are enabled, and the same plan displays other linked models normally. The architectural file uses phases named Existing Conditions and Proposed Work.

Which setting should be reviewed first to resolve this phase-dependent linked-model visibility issue?

The path type assigned to the architectural link in the Manage Links dialog.
The insertion positioning method used when the architectural model was originally linked.
The relative locations of the host and linked project base points in the plan view.
The phase mapping between the host phases and the linked model's differently named phases. (correct answer)

Explanation: Whenever you see a question about linked models behaving differently across phases, your first instinct should be to investigate how Revit maps phases between the host file and the linked file. Revit's phase filters control element visibility based on phase status (new, existing, demolished, temporary), but this system only works correctly when Revit knows which phases in the linked model correspond to which phases in the host. When a linked model uses different phase names than the host — here, "Existing Conditions" and "Proposed Work" versus the host's "Existing" and "New Construction" — Revit cannot automatically align them. The Phase Mapping settings, found in the Visibility/Graphics Overrides dialog under the Revit Links tab, let you specify which linked phase should appear when viewed through each host phase. If this mapping is unconfigured or mismatched, elements from the linked model may appear in one host phase but vanish in another, which is exactly the symptom described. Answer A is a distractor involving path type (Absolute vs. Relative), which affects whether Revit can locate the file — not how it displays by phase. Since the link is confirmed as loaded, path type is irrelevant here. Answer B relates to positioning methods like Auto - Origin to Origin or Shared Coordinates; these affect where the model appears in space, not phase-dependent visibility. Answer C involves project base points, which is similarly a spatial positioning concern, not a visibility-by-phase issue. As a study tip: anytime a linked model is visible in one phase but not another, and the link is confirmed loaded and categories are on, go straight to phase mapping — it's the most common culprit and easy to overlook.

Question 9

Model A contains Model B as a Revit link. Model A is then linked into a campus host model. Model A appears in the campus model, but Model B does not. Model B is loaded and visible when Model A is opened directly.

Which setting in Model A should be checked first to determine why Model B is absent from the campus host?

Whether Model B is assigned to a user-created workset rather than Shared Levels and Grids.
Whether Model B is configured as Overlay rather than Attachment in Model A. (correct answer)
Whether Model B was inserted using Origin to Origin rather than By Shared Coordinates.
Whether Model B uses a linked view rather than the host view for category display.

Explanation: When working with nested Revit links, the key concept to understand is how Revit controls whether a linked model "passes through" to higher-level host models. This is governed by the Attachment vs. Overlay setting, and recognizing this distinction is essential whenever you see a question about links that appear in one model but disappear in another. In Revit, a linked model set to Attachment will travel with its parent model when that parent is linked elsewhere — it becomes visible in the grandparent host. A link set to Overlay, however, stays local: it displays when you open the model directly, but it does not propagate to any host that links that model. This perfectly explains the scenario described — Model B is visible inside Model A but absent in the campus host. Checking the Overlay/Attachment setting in Model A's Manage Links dialog is the correct first step, making B the right answer. A is a distractor about worksharing. Workset visibility affects whether elements display within a single model, not whether a nested link propagates to a host model. C addresses coordinate positioning — Origin to Origin vs. By Shared Coordinates affects where a link lands, not whether it appears at all in a higher-level host. D describes linked view display settings, which control category visibility within views but have no bearing on whether a nested link is transmitted to a campus model. As a study tip: whenever a Revit exam question describes a link that "disappears" when hosted elsewhere, immediately think Overlay vs. Attachment — it's the most common cause of missing nested links on both the exam and in real projects.

Question 10

Before exchanging models, two teams placed their project base points at the same agreed building grid intersection. They have not established shared coordinates, and their internal origins are in different locations. The consultant model is linked using Origin to Origin and appears offset from the agreed grid intersection.

Which correction best uses the coordination information that the teams actually established?

Relink using Center to Center because model extents are more stable than project base points.
Retain Origin to Origin because it automatically aligns both files' project base points.
Relink using Project Base Point to Project Base Point so the agreed base-point locations align. (correct answer)
Use By Shared Coordinates, since the teams' matching base-point positions are sufficient to define a shared-coordinate relationship.

Explanation: Whenever you see a Revit linking question, your first move should be to identify what coordinate information was actually established between the teams. That determines which link placement method is appropriate. In this scenario, both teams placed their project base points at the same agreed grid intersection — that's the specific coordination they set up. They did not run the Acquire/Publish Shared Coordinates workflow, so no shared-coordinate relationship exists between the files. With that framework in mind, the right fix becomes clear: relinking using Project Base Point to Project Base Point (C) directly honors what the teams agreed on. Revit places the linked model so that its project base point lands exactly on the host file's project base point — aligning both files at that agreed grid intersection. A is wrong because Center to Center positions files based on the geometric center of all model elements, which has nothing to do with the grid intersection the teams carefully coordinated. Model extents shift as design evolves, making this method unreliable. B is the most tempting trap: Origin to Origin does not align project base points. It aligns each file's internal origin (0,0,0), which the question explicitly tells you are in different locations — explaining exactly why the model appears offset. D is wrong because By Shared Coordinates requires the Acquire or Publish Shared Coordinates workflow to have been completed. Matching base-point positions alone don't create a shared-coordinate relationship in Revit's data model. Your study tip: memorize that Origin to Origin = internal origins, Project Base Point to Project Base Point = PBPs, and Shared Coordinates = requires the full Acquire/Publish workflow. Confusing these three is one of the most common mistakes on coordination questions.