Which testing sequence is most likely to expose incomplete constraints before the family is released?
Answer: Change each driving parameter separately, then test minimum and maximum combinations while inspecting relevant views after every regeneration.
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."
Which workflow creates the new type without unintentionally changing Base 900?
Answer: Select Base 900, click New Type, name it Base 1200, and then change Width to 1200 mm.
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 mm on the newly created type. Base 900 is never touched after the clone is made, so its Width stays at 900 mm.
Option A is the most tempting trap. Changing Width to 1200 mmbefore 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.
Which modification enables the finish to change correctly when the family types are flexed?
Answer: Create a type-based Material parameter, associate it with the extrusion's Material property, and assign a material in each type.
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.
Which formula and flexing result correctly implement the requirement?
Answer: Use Width>1000 mm; the support is hidden at 1000 mm and visible at 1200 mm.
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. At exactly 1000 mm, the expression evaluates to false, so the support is hidden. At 1200 mm, it evaluates to true, making the support visible. That matches the requirement perfectly.
Answer A uses Width≥1000 mm, which means "greater than or equal to" — so the support would appear at exactly 1000 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, 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, which is the inverse of the correct logic. It would show the support for smaller cabinets (like 900 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 ≥. Read the threshold condition word for word before selecting a formula.
Which correction most directly stabilizes the family while preserving type-driven dimensions?
Answer: Use intersecting reference planes to define the required origin, constrain the mounting corner to them, and flex both types again.
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.
Which family-authoring workflow supports this requirement and permits meaningful type flexing?
Answer: Associate the nested pedestal's type control with a host Family Type parameter, then assign a pedestal type in each host type.
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.
Which formula should drive the Clear Width parameter, and what value should the test type produce?
Answer: Use Clear Width=Overall Width−2×Frame Width, producing 1100 mm.
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 accounts for both sides: 1200−2(50)=1200−100=1100 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 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 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 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.
What is the most appropriate correction before continuing to flex the family?
Answer: Remove or unlock the fixed 900 mm dimension, retain the labeled Width constraint, and retest both types.
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 mm dimension (which rigidly pins the distance at that value). These two constraints coexist peacefully at 900 mm because they agree — but the moment you introduce a 1200 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 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.
Which setup and project test best verify the required behavior?
Answer: Make Width a type parameter; place two doors of one type and confirm that editing the type Width updates both doors.
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.
Which Width formula is dimensionally valid, and what value should the test type produce?
Answer: Use Width=Target Area/Depth, producing a Width of 1200 mm.
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, then solving for Width gives you Width=Target Area/Depth. Dimensionally, this is m2÷m=m — a valid length. Plugging in the test values: 0.72 m2÷0.6 m=1.2 m=1200 mm. That confirms C is correct.
A inverts the division, giving Depth/Target Area=m/m2=m−1, an inverse-length unit — meaningless as a width in Revit. B multiplies instead of divides, producing m×m2=m3, a volume unit, which Revit's formula engine will reject entirely. D applies a square root, giving m2/m=m, a nonsensical fractional dimension that also fails validation — and numerically yields roughly 34.6 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.
