Autodesk Revit Quiz: Family Editor
10 questions · exam conditions
0:00
Family EditorQuestion 1 of 10

An architect opens a furniture RFA directly from a protected company library. The family can be edited, but Revit reports that the original file is read-only when the architect attempts to save it. The approved library file must remain unchanged.

What is the most appropriate next step?

Use Save As to create an editable RFA in a permitted location, then load that copy into the project.
Load the read-only family into a project first, then use Edit Type to remove the file protection.
Use Save to create a temporary local copy automatically, then rename the library file from the project.
Export the family document to RVT format, reopen it, and convert the project back to an RFA file.
← Back to quizzes

Autodesk Revit Quiz

Autodesk Revit Quiz: Family Editor

Practice Family Editor 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 Family Editor, 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

An architect opens a furniture RFA directly from a protected company library. The family can be edited, but Revit reports that the original file is read-only when the architect attempts to save it. The approved library file must remain unchanged.

What is the most appropriate next step?

  1. Use Save As to create an editable RFA in a permitted location, then load that copy into the project. (correct answer)
  2. Load the read-only family into a project first, then use Edit Type to remove the file protection.
  3. Use Save to create a temporary local copy automatically, then rename the library file from the project.
  4. Export the family document to RVT format, reopen it, and convert the project back to an RFA file.
Explanation: When working with Revit families from protected or shared libraries, the core challenge is preserving the original file while still allowing you to make necessary edits. Think of this as a version-control and file-permission problem: the library exists to maintain approved, consistent content, so your workflow must work around the restriction, not try to remove it. The right move is A — using Save As to save a copy of the read-only RFA to a location where you have write permissions. You can then freely edit that copy and load it into your project via the Load Family command. This respects the library's integrity while giving you a fully functional, editable family. B is a misconception trap. Loading a read-only family into a project and using Edit Type only lets you modify type parameters within the project — it does not strip file-level read-only protection from the original RFA on disk. File permissions are an operating system–level attribute, not something Revit's Edit Type dialog can change. C misrepresents how Revit's Save command works. Revit will not silently create a local copy when you save a read-only file; it will simply report an error. You cannot rename a library file "from the project" — that's not a Revit function at all. D describes a workflow that doesn't exist. Revit families (RFA) and projects (RVT) are fundamentally different file types with different environments. You cannot export an RFA as an RVT and then "convert it back" — this round-trip isn't supported. Your study tip: whenever a Revit scenario involves read-only or protected files, Save As is almost always the correct escape hatch — it respects restrictions while enabling your workflow.

Question 2

A consultant sends an RFA saved in a newer release of Revit than the release used by the project team. The team attempts to open the RFA directly, but Revit does not permit it.

Which action correctly addresses the version issue while preserving an editable family workflow?

  1. Rename the RFA extension to RVT, open it in the older release, and save it again as an RFA.
  2. Open the RFA in the same or a newer Revit release, recognizing that an upgraded save cannot be back-saved. (correct answer)
  3. Load the RFA through Insert from File because loading bypasses the Family Editor version restriction.
  4. Open the RFA in the older release as read-only, edit its parameters, and use Save As to downgrade it.
Explanation: Revit file compatibility is strictly one-directional: files saved in a newer release cannot be opened in an older release, and there is no built-in "back-save" or downgrade path. When you encounter a version mismatch question, ask yourself: which direction can Revit files travel, and what are the real consequences of that limitation? The only legitimate resolution here is B — open the RFA in a Revit release that matches or exceeds the file's version. Once opened there, you can edit the family fully in the Family Editor. The critical trade-off is that once you save in that newer release, the file is permanently upgraded and cannot be saved back to the older format. Your team would need to upgrade their Revit installation or use a newer seat to continue working with that family. A is a common misconception — renaming a file extension does nothing to change the underlying binary format. Revit reads file headers, not just extensions, so a renamed RFA will still fail to open in an incompatible release. C is incorrect because the Insert > Load Family command goes through the same version-checking mechanism as directly opening the file; loading does not bypass the version restriction. The family simply won't load if the version is incompatible. D sounds plausible but is false — Revit's older release cannot open the newer file at all, even as read-only. The read-only flag controls editing permissions, not version compatibility. A useful rule of thumb: Revit files are forward-compatible only. Whenever you see options suggesting file renaming, read-only workarounds, or "load bypasses," treat them as traps — Revit's version lock applies universally.

Question 3

A parametric table family changes width correctly, but its legs do not remain aligned with the tabletop edges when the width parameter is flexed. The legs were placed using fixed offsets from unconstrained model geometry.

Which edit most reliably corrects the family behavior?

  1. Move each leg to the correct location for the current type, then disable automatic regeneration before saving.
  2. Add dimensions directly between every solid edge, lock all dimensions, and leave the existing offsets unchanged.
  3. Convert each leg to symbolic lines, constrain the lines to the tabletop, and hide the original solids in plan views.
  4. Add reference planes for the controlling edges, dimension and label them, then align and lock the geometry to those planes. (correct answer)
Explanation: When building parametric families in Revit, the golden rule is that geometry must be driven by reference planes, not placed freely or constrained to solid edges. Reference planes are the skeleton of a family — they respond to parameters, and everything else should follow them. The root cause of the misaligned legs is that they were placed using fixed offsets from geometry that isn't itself tied to any driving parameter. When the width changes, the tabletop stretches, but those raw offset anchors don't move with it. Option D fixes this properly: you create reference planes at the controlling edge positions, attach parameters to the dimensions between them, then align and lock each leg solid to those planes. Now when width flexes, the reference planes move, and the legs move with them — the behavior is reliable and predictable. Option A is a workaround, not a solution. Manually repositioning geometry and disabling regeneration doesn't create any parametric relationship; it just freezes the family in one state and will break again the moment anyone adjusts a parameter. Option B is a common misconception. Locking dimensions between solid edges might seem like it creates constraints, but solid edges are downstream geometry — they shift as a result of parameters, not as a cause. Constraining to them creates circular or fragile dependencies that Revit cannot resolve consistently. Option C replaces structural geometry with symbolic lines, which are 2D annotation elements. They don't represent real 3D solids and would produce misleading documentation with no actual geometry in other views. As a study tip, whenever a Revit family misbehaves during flex, ask yourself: is the geometry pinned to reference planes with locked alignments? That diagnostic question covers the majority of parametric family problems you'll see on the exam.

Question 4

A non-hosted furniture family inserts from a point that is offset from the intended center of the object. The geometry is correctly constrained internally, so moving the solids alone would disturb the design relationships.

Which Family Editor modification most directly corrects the insertion point?

  1. Select the intended intersecting reference planes, enable Defines Origin as appropriate, and keep the geometry constrained to them. (correct answer)
  2. Move all solids to the Internal Origin, delete the reference planes, and reload the family without flexing it.
  3. Create a model line at the intended center, pin the line, and assign it to the family's primary subcategory.
  4. Change the family category to Generic Models, place a temporary instance, and restore the original category afterward.
Explanation: When working in the Revit Family Editor, the insertion point — the spot that snaps to the cursor when you place a family in a project — is controlled by reference planes that have their "Defines Origin" property enabled. These special reference planes mark the family's X and Y (and sometimes Z) origin. If your insertion point feels offset from the intended center, it means the wrong reference planes currently define that origin. The fix, as described in A, is straightforward: identify the reference planes that should intersect at your intended center, enable "Defines Origin" on each of them, and leave all geometry constraints intact. Because the solids remain tied to their existing reference planes, nothing moves — you're simply re-declaring which planes represent the family's home position. This is the most direct, non-destructive correction available. B is a trap for students who confuse the insertion point with geometry position. Moving all solids to the Internal Origin physically relocates geometry and breaks carefully maintained parametric constraints — exactly what the passage warns against. Deleting reference planes would further destroy the parametric framework. C confuses insertion-point logic with subcategory assignments. Model lines and subcategories control visibility and graphical organization, not where a family inserts. Pinning a line has no effect on the origin. D is a red herring. Changing the family category doesn't relocate the insertion point; the "Defines Origin" setting is category-agnostic. This approach introduces unnecessary risk of corrupting family behavior. Study tip: Whenever an insertion or origin problem appears on a Revit exam, immediately think "Defines Origin on reference planes" — that property is the dedicated tool for this exact issue.

Question 5

A project contains a manufacturer-provided door, a Basic Wall type, and a custom reception desk created as an in-place component. The door must be modified so that its revised definition can be saved as an RFA file and reused in other projects.

Which workflow should be used to begin the modification?

  1. Select the Basic Wall, choose Edit Type, and save the resulting wall definition as an RFA file.
  2. Select a door instance, choose Edit Family, and save the opened family document as an RFA file. (correct answer)
  3. Select the reception desk, choose Edit In-Place, and export the edited component as an RFA file.
  4. Select a door instance, choose Edit Type, and save the duplicated project type as an RFA file.
Explanation: Whenever you see a Revit question about editing and reusing components across projects, you need to distinguish between the three fundamental element types: system families (walls, floors, ceilings), loadable families (doors, windows, furniture from RFA files), and in-place families (unique, project-specific components). Loadable families are the only type that exist as standalone RFA files, which means they can be opened, edited in the Family Editor, and saved back as RFA files for use in other projects. When you select a door instance and choose Edit Family, Revit opens the underlying family document in the Family Editor — a separate authoring environment where you can modify geometry, parameters, and behavior. From there, you simply use Save As to export the revised definition as an RFA file, making it reusable anywhere. This is exactly why B is correct. A is wrong because Basic Walls are system families. They exist only within a project and cannot be saved as standalone RFA files — their types live in the project's settings, not in external files. C is wrong because in-place components like the reception desk are embedded directly in the project file. The "Edit In-Place" command lets you modify the geometry within the project context, but there is no export path that converts an in-place component directly into a portable RFA file. D is a tempting trap — Edit Type and duplicating a type is the correct approach for adjusting type parameters, but it keeps the definition inside the project. It does not open the Family Editor and cannot produce a shareable RFA file. Your study tip: remember the rule — only loadable families live in RFA files. If a question asks about portability or reuse across projects, the answer almost always involves the Family Editor workflow.

Question 6

A mechanical equipment family should display simplified geometry at Coarse detail and full geometry at Fine detail. Both solids currently appear at every detail level after the family is loaded into a project.

What should be changed in the Family Editor?

  1. Assign each solid to a different family type and use project view filters to select the appropriate type.
  2. Change the family category at each detail level and reload a separate category definition for each project view.
  3. Select each solid and configure its Visibility Settings for the intended detail levels, then reload the family. (correct answer)
  4. Hide each solid temporarily in Family Editor views and save the family while the desired elements are hidden.
Explanation: Whenever you see a question about controlling geometry visibility across detail levels in Revit families, think about the Visibility/Graphics settings available on individual elements within the Family Editor — this is the core mechanism Revit provides for exactly this purpose. Each solid, void, or reference element in a family has its own Visibility Settings, accessible by selecting the element and clicking the Visibility Settings button in the Properties palette (or ribbon). There, you can check or uncheck which detail levels — Coarse, Medium, and Fine — the element should appear in. So for this scenario, you'd select the simplified solid, enable it only at Coarse, then select the detailed solid and enable it only at Medium and Fine. After reloading the family into the project, Revit automatically shows the correct geometry based on each view's detail level. That's exactly what C describes. A is wrong because family types control parameter variations (like dimensions or materials), not visibility by detail level — and project view filters work on categories or parameters, not detail-level geometry switching. B is a fabricated workflow; you cannot change family category per detail level, and Revit doesn't support separate category definitions per view. D describes temporarily hiding elements in the Family Editor view, which only affects what you see while editing — it does not bake visibility rules into the family and has no effect once the family is loaded into a project. A useful rule of thumb: in Revit families, element-level Visibility Settings are almost always the answer when a question involves controlling what appears at different detail levels.

Question 7

A family loaded in a project has a type parameter Width set to a project-specific value. The source RFA is then edited to correct geometry, but its Width value remains at the library default. The geometry correction must be loaded without replacing the project's current Width value.

Which reload option should be selected when Revit reports that the family already exists?

  1. Rename the RFA file before loading so that Revit treats it as a separate family and merges its geometry automatically.
  2. Choose Overwrite existing version and its parameter values, which updates geometry and resets Width to the library default.
  3. Cancel the reload, manually delete every placed instance in the project, and then load the revised RFA as a new family.
  4. Choose Overwrite existing version, but do not choose the option that also overwrites parameter values. (correct answer)
Explanation: Whenever you see a question about loading families in Revit, focus on the distinction between geometry/definition and parameter values — these are two separate things Revit lets you control independently during a reload. When you load a family that already exists in a project, Revit presents a dialog asking how you want to handle the conflict. You have two core choices: overwrite the existing version (updating geometry and type definitions) with parameter values, or overwrite it without replacing parameter values. Choosing to overwrite without replacing parameter values — option D — is exactly right here. It pulls in the corrected geometry from the updated RFA while leaving the project-specific Width value untouched. This is the intended workflow for situations where the library default and the project-specific value have diverged intentionally. Option B is the trap most students fall into. "Overwrite existing version and its parameter values" sounds thorough, but it would reset Width back to the library default, destroying the project-specific value you need to preserve. Option A is incorrect because renaming the RFA creates an entirely new family — Revit would treat it as a different family altogether, meaning you'd have duplicate families in the project and no automatic geometry merge. Option C is a destructive, unnecessary workaround; deleting every placed instance just to reload a family ignores the built-in reload dialog entirely, and it would cause you to lose placement data, hosted relationships, and other instance properties. A good rule of thumb: anytime a question mentions preserving a project-specific parameter during a reload, the answer will involve the overwrite option that excludes parameter value replacement.

Question 8

A workstation family contains a nested drawer-unit family. The workstation is already loaded into a project. While editing the workstation in the Family Editor, a designer discovers that the drawer geometry itself must change, not merely its position within the workstation.

Which sequence ensures that the revised drawer geometry reaches the project?

  1. Edit the nested drawer, reload it into the workstation family, and then reload the workstation family into the project. (correct answer)
  2. Edit the nested drawer, save the workstation family, and reload only the drawer family directly into the project.
  3. Move the nested drawer inside the workstation, reload the workstation, and then edit the drawer type in the project.
  4. Explode the nested drawer inside the workstation, edit its geometry, and reload the drawer as a project group.
Explanation: Whenever you see a question about nested families in Revit, think in terms of a propagation chain: changes must travel through every level of nesting before they reach the project. A nested family is essentially a family living inside another family, so any geometry edit must flow outward through each container. The correct path is A — edit the drawer family in the Family Editor, reload it into the workstation family (so the workstation now contains the updated drawer), and then reload the updated workstation into the project. This respects the full hierarchy: drawer → workstation → project. Each reload step "pushes" the change one level up the chain until it reaches the live project environment. B is tempting but fundamentally broken. Reloading the drawer family directly into the project bypasses the workstation entirely. The project hosts the workstation family, not the drawer family as a standalone element, so the drawer you reload has no home and the workstation geometry remains unchanged. C confuses geometry editing with placement adjustment. Moving the nested drawer repositions it within the workstation but does nothing to alter its actual geometry. Editing a "drawer type in the project" after reloading also doesn't address the core geometry problem — you cannot edit nested family geometry from within the project environment directly. D is a destructive workaround. Exploding a nested family breaks it into raw geometry or ungrouped elements, destroying the parametric relationship entirely. Reloading it as a "project group" is not a valid Revit workflow for families. Study tip: Memorize the nested family propagation rule — edit at the source, reload at every level — because Revit questions frequently test whether you understand that changes don't automatically cascade upward.

Question 9

A wall-hosted light fixture must be redesigned so that the same content can be placed on walls, ceilings, and linked-model faces. In the existing family, changing the category and enabling Work Plane-Based does not provide the required face-hosted placement behavior.

What is the most reliable Family Editor workflow?

  1. Change the existing family to Generic Models, reload it, and restore the Lighting Fixtures category in the project.
  2. Remove the wall host from the existing family, enable Shared, and assign a reference plane as the new host.
  3. Start a family from an appropriate face-based template, transfer or recreate the content, and load the new family. (correct answer)
  4. Open the wall-hosted family from the project, detach it from the host, and save it as a face-based RFA.
Explanation: When working with hosted families in Revit, the template you start from fundamentally determines placement behavior — it's baked into the family's core structure, not something you can fully retrofit afterward. Face-based families use a special reference plane as a generic host, allowing placement on any face: walls, ceilings, floors, or linked-model surfaces. Wall-hosted families, by contrast, have a wall-specific host hardwired into them. The most reliable path is C: start fresh from a face-based template (such as "Face Based.rft" or the face-based lighting fixture template), then transfer or recreate your geometry, parameters, and connectors in the new file. This guarantees the family inherits proper face-hosted behavior from the ground up — no workarounds needed. A is tempting but misguided. Switching to Generic Models changes the category tag and scheduling behavior, but it doesn't convert wall-hosting to face-hosting. The placement logic remains tied to the original template. B introduces confusion. "Shared" controls whether a nested family reports independently in schedules — it has nothing to do with host type. Assigning a reference plane doesn't replicate a face-based host; it just floats the geometry without proper placement constraints. D sounds plausible but doesn't exist as a real workflow. You cannot "detach" a family from its host type and re-save it as a face-based RFA. The host relationship is structural, not a setting you can simply strip out. A good study rule: whenever a question asks about placement flexibility across multiple surface types, think face-based template first. If the existing family's template is wrong, rebuilding is faster and safer than patching.

Question 10

A cabinet family contains a labeled dimension controlled by the type parameter Width. It currently has one type. A second standard width must be added, and both types must be checked for constraint failures before the family is returned to the project.

Which workflow best accomplishes this in the Family Editor?

  1. Duplicate the cabinet instance in the project, change its Width property, and save each instance as a separate RFA.
  2. Create a new type in Family Types, assign its Width value, flex both types, and load the family into the project. (correct answer)
  3. Add an instance parameter named Width, delete the labeled dimension, and test both widths by moving the geometry.
  4. Duplicate the family file in the operating system, change Width in each copy, and load both files under one family name.
Explanation: When working with Revit families that need multiple size variations, think about the Family Types dialog — it's the built-in tool designed specifically for managing parametric variations within a single family file. Questions like this test whether you understand the difference between type parameters, instance parameters, and the proper family-editing workflow. The correct approach, option B, uses exactly the right tools in the right order. Inside the Family Editor, you open Family Types, duplicate the existing type to create a second one, assign the new Width value, then use the "Flex" function (cycling through each type) to verify that geometry updates correctly without constraint errors. Once both types pass, you load the single RFA into the project — clean, efficient, and non-destructive. Option A is fundamentally flawed because you cannot define family types by duplicating instances in a project. Project instances inherit types; they don't create them. Saving instances as separate RFAs isn't even a standard Revit operation. Option C works against the family's existing structure. Deleting the labeled dimension removes the parametric link that makes Width controllable at all, and instance parameters can't drive type-based size variations across multiple types — they vary per placement, not per type definition. Option D creates unnecessary file management chaos. Loading two separate RFA files under the same family name causes conflicts in the project browser and doesn't leverage Revit's multi-type architecture, which exists precisely to avoid this situation. Your study tip: remember that type parameters + Family Types dialog = multiple sizes, one file. Any answer that fragments a single family into multiple files or bypasses the Family Types dialog is almost certainly wrong.