Autodesk Revit Quiz: Creating Family Types
10 questions · exam conditions
0:00
Creating Family TypesQuestion 1 of 10

A casework family currently contains one type named Base 900 with a Width value of 900 mm900\text{ mm}. A second type named Base 1200 is required with a Width value of 1200 mm1200\text{ mm}. All other parameter values must initially match Base 900.

Which workflow creates the new type without unintentionally changing Base 900?

Select Base 900, change Width to 1200 mm1200\text{ mm}, and then click New Type and name it Base 1200.
Select Base 900, click New Type, name it Base 1200, and then change Width to 1200 mm1200\text{ mm}.
Rename Base 900 to Base 1200, change Width to 1200 mm1200\text{ mm}, and then recreate Base 900.
Change Width to 1200 mm1200\text{ mm}, rename the current type Base 1200, and reload the original family file.
← Back to quizzes

Autodesk Revit Quiz

Autodesk Revit Quiz: Creating Family Types

Practice Creating Family Types 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 Creating Family Types, 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 casework family currently contains one type named Base 900 with a Width value of 900 mm900\text{ mm}. A second type named Base 1200 is required with a Width value of 1200 mm1200\text{ mm}. All other parameter values must initially match Base 900.

Which workflow creates the new type without unintentionally changing Base 900?

  1. Select Base 900, change Width to 1200 mm1200\text{ mm}, and then click New Type and name it Base 1200.
  2. Select Base 900, click New Type, name it Base 1200, and then change Width to 1200 mm1200\text{ mm}. (correct answer)
  3. Rename Base 900 to Base 1200, change Width to 1200 mm1200\text{ mm}, and then recreate Base 900.
  4. Change Width to 1200 mm1200\text{ mm}, rename the current type Base 1200, and reload the original family file.
Explanation: When working inside the Revit Family Editor's Type Catalog or Family Types dialog, the order of operations is everything. The key principle: a new type is always created as a copy of whichever type is currently active at the moment you click New Type. That means you must duplicate first, then modify — not modify first, then duplicate. Option B is correct because it follows this exact sequence. You start with Base 900 selected (so all its parameter values are loaded), click New Type to clone it under the name Base 1200, and then change Width to 1200 mm1200\text{ mm} on the newly created type. Base 900 is never touched after the clone is made, so its Width stays at 900 mm900\text{ mm}. Option A is the most tempting trap. Changing Width to 1200 mm1200\text{ mm} before clicking New Type modifies Base 900 directly — the moment you hit Enter, that change is live on Base 900. You've now corrupted the original type before even creating the new one. Option C destroys Base 900 entirely by renaming it, forcing you to manually rebuild it from scratch — a slow, error-prone process that contradicts the goal of preserving the original. Option D involves renaming and then reloading the original file, which is unreliable and project-destructive; reloading a family can overwrite project-level changes and is not a standard workflow for adding types. Study tip: On Revit exam questions about family types, always ask yourself when the modification happens relative to the duplication. Duplicate first, edit second — that's the safe rule.

Question 2

A countertop family requires Laminate and Stone types with identical geometry but different finishes. The countertop extrusion currently uses a fixed material selected directly in its properties.

Which modification enables the finish to change correctly when the family types are flexed?

  1. Create a type-based Image parameter, associate it with the extrusion, and store a rendering image for each finish.
  2. Create an instance-based Text parameter, enter each material name, and assign one fixed material to the extrusion.
  3. Duplicate the extrusion for each finish, leave both materials fixed, and control only the duplicate extrusion's subcategory.
  4. Create a type-based Material parameter, associate it with the extrusion's Material property, and assign a material in each type. (correct answer)
Explanation: Whenever you see a question about family types sharing the same geometry but needing different material appearances in Revit, think about type parameters. The key distinction is between fixed properties baked into the geometry and driven properties that respond to the active family type. In a Revit family, if you want a property to change when you switch between types (like Laminate vs. Stone), that property must be controlled by a parameter assigned to each type. The correct approach — answer D — is to create a type-based Material parameter, then associate it with the extrusion's Material property using the small association button in the family editor. Once linked, you assign a specific material to each type (Laminate type gets a laminate material, Stone type gets a stone material). When you flex the family by switching types, Revit swaps the material automatically. This is the standard workflow for material-driven type variations. A is wrong because an Image parameter stores a rendering bitmap, not a material definition. It has no connection to how Revit renders or schedules materials in the model. B fails on two counts: a Text parameter cannot be associated with a Material property, and keeping a fixed material on the extrusion means the finish never changes regardless of the parameter value. C duplicates geometry unnecessarily and still relies on fixed materials — switching subcategories controls visibility and line weights, not material finish. As a study tip: in Revit family questions, always match parameter type to property type — Material properties require Material parameters, not Text or Image. Also remember that type parameters drive type-by-type variation, while instance parameters drive per-placement variation.

Question 3

A framed panel family has type parameters Overall Width and Frame Width. The clear opening must remain centered, with equal framing on both sides. For one test type, Overall Width is 1200 mm1200\text{ mm} and Frame Width is 50 mm50\text{ mm}.

Which formula should drive the Clear Width parameter, and what value should the test type produce?

  1. Use Clear Width=Overall Width−Frame Width\text{Clear Width}=\text{Overall Width}-\text{Frame Width}, producing 1150 mm1150\text{ mm}.
  2. Use Clear Width=Overall Width−2×Frame Width\text{Clear Width}=\text{Overall Width}-2\times\text{Frame Width}, producing 1100 mm1100\text{ mm}. (correct answer)
  3. Use Clear Width=Overall Width/2−Frame Width\text{Clear Width}=\text{Overall Width}/2-\text{Frame Width}, producing 550 mm550\text{ mm}.
  4. Use Clear Width=Overall Width+2×Frame Width\text{Clear Width}=\text{Overall Width}+2\times\text{Frame Width}, producing 1300 mm1300\text{ mm}.
Explanation: When building parametric panel families in Revit, you need to think geometrically about how components relate to the overall dimension. Picture the panel from above: the total width contains a frame piece on the left, the clear opening in the middle, and a frame piece on the right. That means two frame widths are consumed before you get your usable opening. This makes B the correct choice. The formula Clear Width=Overall Width−2×Frame Width\text{Clear Width} = \text{Overall Width} - 2 \times \text{Frame Width} accounts for both sides: 1200−2(50)=1200−100=1100 mm1200 - 2(50) = 1200 - 100 = 1100\text{ mm}. The opening stays centered automatically because the same Frame Width value is subtracted symmetrically from each side — no additional centering constraint is needed. A subtracts only one Frame Width, giving 1150 mm1150\text{ mm}. This would be correct if framing existed on only one side, but the problem explicitly states equal framing on both sides — so this formula leaves one side unaccounted for. C divides the Overall Width by 2 first, then subtracts one Frame Width, yielding 550 mm550\text{ mm}. This formula calculates only half the clear opening (perhaps useful for a symmetry reference plane), not the full Clear Width. It conflates half-width geometry with the total dimension. D adds frame widths instead of subtracting them, producing 1300 mm1300\text{ mm} — larger than the panel itself. Adding frame material cannot increase the opening; this reverses the relationship entirely. Study tip: Whenever a Revit parameter question involves bilateral symmetry (equal components on both sides), immediately ask yourself, "How many instances of this element exist?" That count becomes your multiplier in the formula.

Question 4

A cabinet family includes an optional center support. Its Visibility property is associated with a Yes/No type parameter named Center Support Visible. The support should appear only when Width is greater than 1000 mm1000\text{ mm}.

Which formula and flexing result correctly implement the requirement?

  1. Use Width≥1000 mm\text{Width}\geq1000\text{ mm}; the support is visible in both 1000 mm1000\text{ mm} and 1200 mm1200\text{ mm} types.
  2. Use Width=1000 mm\text{Width}=1000\text{ mm}; the support is visible only in the 1000 mm1000\text{ mm} type.
  3. Use Width<1000 mm\text{Width}<1000\text{ mm}; the support is visible at 900 mm900\text{ mm} and hidden at 1200 mm1200\text{ mm}.
  4. Use Width>1000 mm\text{Width}>1000\text{ mm}; the support is hidden at 1000 mm1000\text{ mm} and visible at 1200 mm1200\text{ mm}. (correct answer)
Explanation: When working with conditional visibility in Revit families, you need to connect two things: the logical formula driving a Yes/No parameter, and the real-world behavior you'd observe when flexing the family across different type sizes. The formula must precisely match the stated condition — here, "only when Width is greater than 1000 mm." Answer D correctly implements this with Width>1000 mm\text{Width} > 1000\text{ mm}. At exactly 1000 mm1000\text{ mm}, the expression evaluates to false, so the support is hidden. At 1200 mm1200\text{ mm}, it evaluates to true, making the support visible. That matches the requirement perfectly. Answer A uses Width≥1000 mm\text{Width} \geq 1000\text{ mm}, which means "greater than or equal to" — so the support would appear at exactly 1000 mm1000\text{ mm} as well. This violates the spec, which says support appears only when Width exceeds 1000 mm. It's a classic off-by-one logic trap. Answer B uses Width=1000 mm\text{Width} = 1000\text{ mm}, which is an equality check — the support only appears at that exact width and disappears everywhere else. This is the opposite of the intended behavior. Answer C uses Width<1000 mm\text{Width} < 1000\text{ mm}, which is the inverse of the correct logic. It would show the support for smaller cabinets (like 900 mm900\text{ mm}) and hide it for larger ones — completely backwards. When you see visibility-formula questions on the Revit exam, always map the plain-English requirement to its strict mathematical operator: "only when greater than" means >>, never ≥\geq. Read the threshold condition word for word before selecting a formula.

Question 5

A host desk family contains a nested pedestal family with predefined types Two Drawer and Three Drawer. The host must have desk types that select the required pedestal configuration without editing the nested family manually.

Which family-authoring workflow supports this requirement and permits meaningful type flexing?

  1. Associate the nested pedestal's type control with a host Family Type parameter, then assign a pedestal type in each host type. (correct answer)
  2. Associate the pedestal's width dimension with a host length parameter, then calculate the drawer count from the resulting width.
  3. Make the nested pedestal shared, leave its type unassociated, and select a pedestal type after each host instance is placed.
  4. Create a visibility parameter for each pedestal type, then keep every nested pedestal visible while testing the host types.
Explanation: When you see a question about nested families and type control in Revit, focus on how the host family communicates configuration choices to its nested components without manual intervention on each instance. The key mechanism here is the Family Type parameter. When you add a parameter of type "Family Type" to the host family and associate it with the nested pedestal's type dropdown, each host desk type can store a specific pedestal type selection — "Two Drawer" or "Three Drawer" — directly in the type properties. This is exactly what Answer A describes, and it's the only workflow that makes type flexing meaningful: swap the host type, and the pedestal configuration updates automatically. Answer B takes the wrong approach by trying to derive drawer count from a dimensional parameter. Width doesn't inherently encode drawer quantity, and Revit families don't perform that kind of conditional logic through simple length parameters. You'd be fighting the tool rather than using its built-in type system. Answer C makes the pedestal shared and leaves type selection to the user after placement. While sharing a nested family has legitimate uses (scheduling, tagging), it abandons the goal of automated type control. Every placed instance would require manual pedestal-type selection, which defeats the requirement. Answer D is a common trap: using visibility parameters to show/hide different nested families is a legitimate pattern for geometry toggling, but keeping every pedestal visible simultaneously means all types appear at once, which is functionally broken for this use case. Remember: whenever a nested family has predefined types that need to flex with the host, your first instinct should be a Family Type parameter — it's Revit's purpose-built tool for exactly this scenario.

Question 6

A door family must provide predefined widths. Every door assigned to the same type must retain the same Width, although individual instances may be assigned to different types.

Which setup and project test best verify the required behavior?

  1. Make Width an instance parameter; place two doors of one type and confirm that changing one Width leaves the other unchanged.
  2. Make Width a type parameter; place two doors of one type and confirm that editing the type Width updates both doors. (correct answer)
  3. Make Width a reporting parameter; place two doors and confirm that their host walls calculate matching Width values.
  4. Make Width a shared instance parameter; place two doors and confirm that a schedule can report separate Width values.
Explanation: Whenever you see a Revit question about controlling how a parameter behaves across multiple instances of the same family type, you need to distinguish between type parameters and instance parameters. Type parameters store a single value shared by every instance of that type, while instance parameters allow each placed instance to carry its own independent value. The passage states two requirements: Width must be predefined per type, and all doors of the same type must share the same Width. This is exactly what a type parameter does — editing the Width on any one door updates every door assigned to that type simultaneously. Choice B correctly captures this by having you place two doors of the same type and confirming that a single edit propagates to both, which directly validates the "same type = same Width" requirement. Choice A describes an instance parameter, which does the opposite of what's needed. If you can change one door's Width without affecting the other, that means each door holds its own value — violating the requirement that all doors of the same type retain the same Width. Choice C involves a reporting parameter, which is a read-only parameter that captures a geometric value driven by constraints or other parameters. It doesn't let you define or control Width as a predefined property — it just reports an existing measurement. Choice D describes a shared instance parameter, which still behaves as an instance parameter. Shared parameters add schedulability and cross-family tagging ability, but "shared" doesn't change whether the parameter is type-level or instance-level. Separate schedulable values still mean each door can differ, violating the passage's constraint. Your study tip: always map each parameter type to its core behavior — type = uniform across all instances of a type, instance = unique per placement. The exam frequently tests whether you can identify which behavior a given scenario demands.

Question 7

A parametric equipment family has Width, Height, and Depth type parameters. The default type regenerates correctly, but the family will be issued with several substantially different sizes.

Which testing sequence is most likely to expose incomplete constraints before the family is released?

  1. Create all required type names first, keep their values equal to the default, and rely on project users to identify constraint failures.
  2. Change all driving parameters to maximum values simultaneously, save once if regeneration succeeds, and avoid returning to smaller values.
  3. Change each driving parameter separately, then test minimum and maximum combinations while inspecting relevant views after every regeneration. (correct answer)
  4. Test only the default type in a three-dimensional view, because successful regeneration verifies every possible parameter combination.
Explanation: When testing a parametric family in Revit, your goal is to expose constraint failures before users encounter them in a project. A well-constrained family should regenerate cleanly at any valid combination of parameter values — not just at the defaults. This question tests whether you understand systematic parametric validation. The most reliable approach, as described in C, is isolating each parameter first (changing Width alone, then Height alone, then Depth alone) before testing boundary combinations (minimum + minimum, maximum + maximum, and mixed extremes). Inspecting relevant views — plans, elevations, sections — after each regeneration ensures you catch reference plane collapses, negative geometry, or unconstrained elements that only appear at specific sizes. Choice A is essentially no testing at all. Keeping values equal to the default tells you nothing about behavior at other sizes, and offloading discovery to project users is unprofessional and potentially costly to fix post-release. Choice B partially addresses scale but introduces a critical flaw: testing maximum values simultaneously without intermediate steps means you can't isolate which parameter caused a failure if regeneration breaks. Skipping smaller values also leaves minimum-size behavior entirely untested. Choice D is the most dangerous misconception — that one successful regeneration in 3D "verifies every possible combination." Parametric families can fail selectively; a family that looks correct at default values may collapse when Width is small and Depth is large. No single test state can validate an entire parameter space. Study tip: Think of parametric family testing like a structured quality checklist — isolate variables, then test extremes. Any question about family validation should trigger the phrase "boundary conditions + view inspection."

Question 8

In a furniture family, the left and right reference planes are controlled by a labeled Width dimension. An older, unlabeled dimension between the same planes is also locked at 900 mm900\text{ mm}. The 900 mm900\text{ mm} type regenerates, but a new 1200 mm1200\text{ mm} type produces a constraints-not-satisfied warning.

What is the most appropriate correction before continuing to flex the family?

  1. Remove or unlock the fixed 900 mm900\text{ mm} dimension, retain the labeled Width constraint, and retest both types. (correct answer)
  2. Remove the labeled Width dimension, retain the fixed 900 mm900\text{ mm} dimension, and resize the extrusion in each type.
  3. Convert Width from a type parameter to an instance parameter, retain both dimensions, and test another instance.
  4. Keep both dimensions, delete the 1200 mm1200\text{ mm} type, and create a type with a value closer to 900 mm900\text{ mm}.
Explanation: When building Revit families, a "constraints-not-satisfied" warning almost always signals a conflict between two competing constraints trying to control the same geometry simultaneously. Here, two dimensions govern the exact same reference planes: the labeled Width parameter (which should drive the width flexibly) and a separate, locked 900 mm900\text{ mm} dimension (which rigidly pins the distance at that value). These two constraints coexist peacefully at 900 mm900\text{ mm} because they agree — but the moment you introduce a 1200 mm1200\text{ mm} type, the labeled parameter tries to push the planes apart while the locked dimension refuses to move, causing the conflict. The correct fix is A: remove or unlock the redundant fixed dimension so only the labeled Width parameter controls the planes, then retest both types. With one authoritative constraint driving the geometry, the family can flex cleanly to any value. B is backwards — discarding the labeled parameter means losing parametric control entirely, forcing you to manually resize geometry for every type, which defeats the purpose of a parametric family. C misdiagnoses the problem; switching Width to an instance parameter doesn't resolve the locked dimension conflict — both constraints still fight each other, just at the instance level. D is an avoidance strategy, not a fix — deleting the 1200 mm1200\text{ mm} type masks the underlying constraint error rather than correcting it, leaving the family broken for any future width variation. A useful rule of thumb: one geometry, one controlling constraint. Whenever you see a warning during flexing, audit your dimensions for duplicates before investigating anything else.

Question 9

A rectangular panel family has type parameters Target Area, Depth, and Width. Width must be calculated so that the face area remains equal to Target Area. A test type has Target Area of 0.72 m20.72\text{ m}^2 and Depth of 600 mm600\text{ mm}.

Which Width formula is dimensionally valid, and what value should the test type produce?

  1. Use Width=Depth/Target Area\text{Width}=\text{Depth}/\text{Target Area}, producing a Width based on inverse-length units.
  2. Use Width=Target Area×Depth\text{Width}=\text{Target Area}\times\text{Depth}, producing a Width based on cubic units.
  3. Use Width=Target Area/Depth\text{Width}=\text{Target Area}/\text{Depth}, producing a Width of 1200 mm1200\text{ mm}. (correct answer)
  4. Use Width=Target Area/Depth\text{Width}=\sqrt{\text{Target Area}/\text{Depth}}, producing a Width of about 34.6 mm34.6\text{ mm}.
Explanation: Whenever you encounter formula questions in Revit family parameters, treat them like a dimensional analysis problem: the units on both sides of the equation must match. Width is a length, so your formula must produce units of length — nothing more, nothing less. The relationship you need here is straightforward geometry. If a rectangular face has area equal to Target Area=Width×Depth\text{Target Area} = \text{Width} \times \text{Depth}, then solving for Width gives you Width=Target Area/Depth\text{Width} = \text{Target Area} / \text{Depth}. Dimensionally, this is m2÷m=m\text{m}^2 \div \text{m} = \text{m} — a valid length. Plugging in the test values: 0.72 m2÷0.6 m=1.2 m=1200 mm0.72\text{ m}^2 \div 0.6\text{ m} = 1.2\text{ m} = 1200\text{ mm}. That confirms C is correct. A inverts the division, giving Depth/Target Area=m/m2=m−1\text{Depth} / \text{Target Area} = \text{m} / \text{m}^2 = \text{m}^{-1}, an inverse-length unit — meaningless as a width in Revit. B multiplies instead of divides, producing m×m2=m3\text{m} \times \text{m}^2 = \text{m}^3, a volume unit, which Revit's formula engine will reject entirely. D applies a square root, giving m2/m=m\sqrt{\text{m}^2 / \text{m}} = \sqrt{\text{m}}, a nonsensical fractional dimension that also fails validation — and numerically yields roughly 34.6 mm34.6\text{ mm}, far from the expected result. As a study habit, always check your Revit parameter formulas by writing out the units explicitly before testing them. If the units don't cancel to the correct dimension, Revit will throw an error and the formula won't save.

Question 10

A wall-mounted fixture has Small and Large family types. When the family is flexed from Small to Large, its geometry expands to the right and upward as intended, but the insertion point also shifts relative to the wall. The mounting corner must remain fixed for every type.

Which correction most directly stabilizes the family while preserving type-driven dimensions?

  1. Use intersecting reference planes to define the required origin, constrain the mounting corner to them, and flex both types again. (correct answer)
  2. Pin the fixture geometry in the Large type, leave the origin unchanged, and reload only that type into the project.
  3. Move each type's geometry back to the mounting corner after flexing, without adding reference-plane constraints.
  4. Convert the Width and Height parameters to instance parameters so users can realign each placed fixture manually.
Explanation: Whenever you see a Revit family flexibility question, focus on where the origin is defined and how geometry is anchored to it. The origin of a family is controlled by its reference planes, and the insertion point in a project is wherever that origin lands on the wall. If geometry drifts when you flex types, the problem is almost always that nothing is constraining the critical corner to the origin planes. Option A is correct because it addresses the root cause. By placing two intersecting reference planes at the mounting corner and constraining that corner to them, you give the family a stable, type-independent anchor. When you flex from Small to Large, the geometry expands outward from that fixed corner — the insertion point never moves. This is the standard Revit workflow for controlling family behavior across types. Option B is a dead end. Pinning geometry locks it in place within the project environment, not within the family editor. It doesn't fix the parametric definition, and it would break as soon as someone places or reloads the family normally. Option C describes a manual workaround that doesn't scale. Moving geometry back each time you flex doesn't add any parametric constraint, so the drift will reappear whenever a type changes. You're patching symptoms, not fixing the cause. Option D makes the problem worse. Converting dimensions to instance parameters means every user must manually realign placed fixtures — that defeats the purpose of a well-built family entirely and introduces human error at the project level. Study tip: In the family editor, always ask "what is pinned to the origin?" before flexing. Reference planes constrain geometry; without them, type changes have nothing stable to push against.