Autodesk Revit Quiz: Type Vs Instance Parameters
10 questions · exam conditions
0:00
Type Vs Instance ParametersQuestion 1 of 10

Eighty interior walls use the type Partition-100. Twelve of those walls must receive a thicker gypsum layer, while the remaining walls must retain the current construction. The type may also be used in views that are not currently open.

Which workflow produces the required result with the least risk of unintended changes?

Edit Partition-100, change its gypsum thickness, and restore the other 68 walls individually
Duplicate Partition-100, modify the duplicate, and assign the 12 walls to the new type
Change an instance thickness value for each of the 12 walls without creating another type
Rename Partition-100, modify its structure, and assign its former name to the other walls
← Back to quizzes

Autodesk Revit Quiz

Autodesk Revit Quiz: Type Vs Instance Parameters

Practice Type Vs Instance Parameters 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 Type Vs Instance Parameters, 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

Eighty interior walls use the type Partition-100. Twelve of those walls must receive a thicker gypsum layer, while the remaining walls must retain the current construction. The type may also be used in views that are not currently open.

Which workflow produces the required result with the least risk of unintended changes?

  1. Edit Partition-100, change its gypsum thickness, and restore the other 68 walls individually
  2. Duplicate Partition-100, modify the duplicate, and assign the 12 walls to the new type (correct answer)
  3. Change an instance thickness value for each of the 12 walls without creating another type
  4. Rename Partition-100, modify its structure, and assign its former name to the other walls
Explanation: Whenever Revit questions describe a scenario where some but not all instances of a type need different properties, your first instinct should be: this requires a new wall type, not a type edit. Because wall construction (layer thickness) is a type property in Revit, any change to a type propagates instantly to every wall using that type — including walls in views you haven't opened. That's the core risk the question is testing. Duplicating Partition-100 and modifying the copy is the safest, most professional workflow. You create a new type (say, Partition-100-Thick), adjust only its gypsum layer, then reassign just the 12 target walls to it. The original 68 walls are never touched, and no views are accidentally affected. This is option B, the correct answer. A is dangerous precisely because of the closed-views warning in the passage. Editing the live type first changes all 80 walls immediately, and manually restoring 68 of them is error-prone — you could easily miss walls in unopened views. C sounds appealing, but wall layer thicknesses are type properties, not instance properties. Revit does not allow you to override individual layer dimensions at the instance level, so this option is technically impossible in standard wall workflows. D creates unnecessary confusion: renaming the type and reassigning a name is roundabout and still risks touching walls in closed views during the renaming/modification process. It also introduces naming inconsistency across the project. The study tip here: on the Revit exam, whenever a subset of instances needs a different type property, the answer almost always involves duplicating the type — never editing the shared one.

Question 2

A casework family includes a visibility parameter named Show Backsplash. The parameter is currently defined as a type parameter. In one room, three instances of the same casework type are placed, but only one of them should display the backsplash.

Which modification most directly supports the requirement without creating another casework type?

  1. Keep the parameter type-based and turn it off from the selected casework instance
  2. Redefine Show Backsplash as an instance parameter and control it on each placement (correct answer)
  3. Keep the parameter type-based and change its value through an instance schedule field
  4. Redefine Show Backsplash as a reporting parameter and edit the reported value
Explanation: Whenever you see a question about controlling visibility differently across instances of the same family type, you need to think about the fundamental distinction between type parameters and instance parameters in Revit families. A type parameter stores a single value shared by every instance of that type — if you change it, every placement updates simultaneously. An instance parameter, by contrast, stores a value per placement, letting each instance behave independently without requiring a new type. Since the goal is to show the backsplash on only one of three identical casework instances — without creating a new type — the solution is to redefine Show Backsplash as an instance parameter inside the family editor. Once saved and reloaded, you can toggle the parameter on or off for each placed instance individually. This is exactly what B describes, making it the correct answer. A is the most common trap here: you cannot override a type parameter at the instance level. Type parameters are locked to the type — there is no per-instance override available in the Properties palette for them. C is also incorrect. Schedules can display type parameter values, but they cannot split a single type's parameter into different values per instance. Editing a type field in a schedule still changes every instance of that type. D misunderstands reporting parameters entirely. Reporting parameters are read-only values that capture dimensional data driven by geometry — they cannot be manually set or toggled for visibility control. As a study strategy, remember this rule: if behavior needs to vary per placement, it must be an instance parameter. Any time a question says "without creating another type," think instance parameters first.

Question 3

A custom lighting family uses Housing Depth to drive a labeled dimension. The parameter is defined as a type parameter. Ten fixtures of one type are placed, and only two fixtures must be extended to different depths while keeping the same photometric type information.

What is the most appropriate family-parameter change if the depth must remain independently editable on each placed fixture?

  1. Change Housing Depth to an instance parameter and verify that the family flexes independently (correct answer)
  2. Leave Housing Depth as a type parameter and edit it separately from each selected fixture
  3. Change Housing Depth to a reporting parameter and enter a depth for each fixture
  4. Leave Housing Depth type-based and rename each affected fixture after changing the depth
Explanation: When working with Revit families, one of the most important distinctions you need to understand is the difference between type parameters and instance parameters. Type parameters apply uniformly to every placed instance of a given type — changing one changes all ten fixtures simultaneously. Instance parameters, by contrast, allow each placed element to hold its own independent value while still belonging to the same type. This scenario is the classic use case for converting a type parameter to an instance parameter. Since two fixtures need unique depths while sharing the same photometric data (meaning they should stay the same type), the only clean solution is to make Housing Depth an instance parameter. Once converted and the family is reloaded, you can select each of those two fixtures individually and enter a different depth without affecting the other eight. Choice A is correct — and the extra step of verifying the family "flexes" independently is good practice to confirm no constraints break during the conversion. Choice B is wrong because type parameters cannot be edited per-fixture from the Properties palette; changing a type parameter always propagates to every instance of that type, which would alter all ten fixtures, not just two. Choice C misunderstands reporting parameters entirely — they read a value driven by geometry (like a measurement), they cannot be used to input or drive a dimension. Choice D is a workaround that would create duplicate family types for just a depth change, which clutters the project and defeats proper parametric workflow. A good study rule: whenever a question involves some but not all instances needing unique values, your answer almost always involves instance parameters.

Question 4

A shared parameter named Asset Classification is added to the Mechanical Equipment category as a type-bound project parameter. Four pumps use type P-100, and three pumps use type P-200. A user enters a new classification while working from one P-100 pump.

Assuming the value is edited in Type Properties, which elements receive the new classification?

  1. Only the selected P-100 pump, because project parameters are always instance-specific
  2. Only the P-100 pumps visible in the active view, because hidden instances are excluded
  3. All seven pumps, because the parameter is bound to the Mechanical Equipment category
  4. All four P-100 pumps, because they reference the edited type's parameter value (correct answer)
Explanation: Whenever you see a question about Revit parameters, the first thing to identify is whether the parameter is instance-bound or type-bound — this single distinction determines how widely a value propagates. A type-bound parameter stores its value at the type level, meaning every element that shares that type references the same value. When you open Type Properties for a P-100 pump and edit a type-bound parameter, you are modifying the type definition itself — not the individual element you clicked on. Because all four P-100 pumps reference that same type, they all immediately reflect the updated value. That makes D the correct answer. Here's why the other choices miss the mark. A is wrong because it confuses type parameters with instance parameters. Instance parameters are element-specific; type parameters are shared across all instances of that type — editing them in Type Properties is the clearest signal that you're working at the type level, not the instance level. B introduces a view-visibility rule that simply doesn't exist in Revit's parameter system; view visibility controls what you see, not what gets updated when type data changes. C is tempting because the parameter is bound to the Mechanical Equipment category, but that only means it appears on all elements in that category — it doesn't flatten the distinction between types. P-200 pumps belong to a different type, so editing P-100's type definition leaves P-200 untouched. A good study habit here: when a Revit question mentions "Type Properties," immediately think all instances of that type are affected — that's the core rule, and exam questions frequently test whether you confuse type scope with category scope or instance scope.

Question 5

A project initially contains 12 chairs of type A and 5 chairs of type B. A designer selects 3 of the type A chairs and changes their Type Selector value to the existing type B. The designer then opens Edit Type from one of those chairs and changes type B's seat width.

How many chairs receive the new seat width, and why?

  1. Exactly 3 chairs, because only the chairs selected before opening Edit Type are modified
  2. Exactly 5 chairs, because the Type Selector reassignment does not make the 3 chairs part of type B before Edit Type is opened
  3. Exactly 8 chairs, because all current instances assigned to type B share its definition (correct answer)
  4. All 17 chairs, because editing one chair type updates every chair in the family
Explanation: Whenever you see a question about editing element types in Revit, the key concept to keep in mind is the difference between instances and types. An instance is one specific element placed in the model; a type is the shared definition that governs all instances assigned to it. Editing a type property changes every instance that belongs to that type — past, present, and the three newly reassigned ones. Here's how the logic flows: when the designer reassigns those 3 type A chairs to type B via the Type Selector, those chairs fully become type B instances. They are no longer type A in any sense. At that moment, type B has 5 original chairs plus 3 reassigned chairs — 8 total. When the designer opens Edit Type from any one of those chairs and changes the seat width, that modification applies to the type definition itself, not to any individual chair. All 8 instances sharing that definition immediately reflect the change. That makes C correct. Choice A is wrong because Edit Type doesn't work on selections — it modifies the type definition, which propagates to all instances regardless of what was selected. Choice B misunderstands the Type Selector; once you reassign an instance to type B, it is definitively type B before Edit Type is ever opened — the reassignment is complete and immediate. Choice D overstates the scope: Edit Type only affects the specific type being edited (type B), not every type in the family. Type A's 9 remaining chairs are untouched. As a study tip, remember this rule: Instance properties affect one element; Type properties affect all elements sharing that type. This distinction appears constantly on Revit exam questions.

Question 6

A project contains 36 exterior walls assigned to the type Basic Wall: Exterior-200. In the Type Properties dialog, a designer changes the type's compound structure by increasing the insulation layer thickness. Of the 36 walls, 8 are hidden in the current view and 5 are in a different design option.

Which walls are affected after the designer confirms the type change?

  1. Only the 23 visible walls in the active view and active design option
  2. All 36 walls assigned to Exterior-200, including hidden and option-specific walls (correct answer)
  3. Only the wall used to open Type Properties, because layer thickness is instance-specific
  4. All exterior-category walls in the project, regardless of their assigned wall type
Explanation: Whenever you see a question about Type Properties in Revit, anchor your thinking to one core principle: type parameters are shared by every element assigned to that type, across the entire project, no exceptions. In Revit's parametric framework, wall types like Exterior-200 act as a single shared definition. Every wall instance that references that type inherits its compound structure — including layer thicknesses. When you edit the type's insulation layer in the Type Properties dialog, you're modifying the definition itself, not any individual wall. Revit then propagates that change to all 36 walls simultaneously. Hidden walls are simply invisible in the current view but still exist in the model and remain linked to the same type. Walls inside a design option belong to an alternate design scenario but are still assigned to Exterior-200, so they're updated too. Answer B is correct. A is wrong because view visibility has no bearing on type definitions. Hiding a wall in a view doesn't disconnect it from its type — it's just a display setting. C reflects a common misconception: layer thickness lives in Type Properties, not Instance Properties. Instance parameters (like wall height or base offset) vary per element, but compound structure is always type-level. There's no way to change insulation thickness for just one wall without creating a new type. D is wrong because the change is scoped to walls assigned specifically to Exterior-200. Walls of a different type — say, Exterior-300 — are completely unaffected. Study tip: On Revit exam questions, always ask yourself "is this parameter type-level or instance-level?" Type edits ripple everywhere; instance edits affect only that one element.

Question 7

A door schedule contains one row per door. Six doors use the type D1. The scheduled field Type Comments is a type parameter, while Installation Note is an instance parameter. A coordinator edits both cells from the row for door 101.

After the edits, what should the coordinator expect in the schedule?

  1. The new type comment appears for all six D1 doors, but the installation note changes only for door 101 (correct answer)
  2. Both new values appear only for door 101 because the schedule displays separate instance rows
  3. Both new values appear for all six D1 doors because schedule edits always update the family type
  4. The type comment changes only for door 101, but the installation note appears for all D1 doors
Explanation: Whenever you see a Revit schedule question involving edits to parameter values, the critical distinction to make is whether each parameter is a type parameter or an instance parameter — because this determines the scope of any change you make. Type parameters are shared across every element that uses the same family type. When you edit a type parameter in a schedule — like Type Comments for door type D1 — Revit is essentially editing the type definition itself. Every door using D1 inherits that change automatically, so all six D1 doors will reflect the new value. Instance parameters, by contrast, belong exclusively to a single element. Editing Installation Note for door 101 only affects that one door, leaving the other five D1 doors untouched. That logic confirms A as correct: the type comment propagates to all six D1 doors, while the installation note updates only door 101. B is wrong because it assumes schedule rows act as isolated records — they don't. Type parameter edits ripple across all elements sharing that type, regardless of which row you click. C is wrong in the opposite direction: it overgeneralizes, claiming all schedule edits update the family type. Only type parameter edits do this; instance parameter edits remain local. D reverses the logic entirely, incorrectly assigning the broad scope to the instance parameter and the narrow scope to the type parameter — exactly backward. A reliable study tip: when reviewing Revit parameters, always ask yourself "does this live on the type or the instance?" Type = shared, Instance = individual. That single question will resolve most schedule and parameter questions on the exam.

Question 8

A door tag displays the shared parameter Type Mark, which is defined as a type parameter. Four doors use type A, and two doors use type B. A user changes the displayed Type Mark by editing the parameter from one tagged type A door.

What is the expected effect on the door tags?

  1. Only the edited door's tag changes because each tag is an independent annotation instance
  2. The tag text changes only in the active view because type parameters are view-specific
  3. All six door tags display the new value because they use the same tag family
  4. All type A door tags display the new value, while type B door tags remain unchanged (correct answer)
Explanation: Whenever you see a question about tags and parameters in Revit, the first thing to ask yourself is: is this a type parameter or an instance parameter? That distinction drives everything. In Revit, type parameters are shared across all elements of the same family type. If four doors all use "Type A," they are literally the same type — meaning they share one set of type parameter values. When you edit a type parameter from any one of those doors (even through its tag), you are editing the type itself, not just that individual door. Every element belonging to that type immediately reflects the change. That's exactly why D is correct: all four Type A doors update, while the two Type B doors — belonging to a different type with its own parameter value — remain untouched. Answer A is wrong because it confuses type parameters with instance parameters. Instance parameters would affect only the edited element, but Type Mark here is explicitly a type parameter. Answer B is wrong because type parameters have nothing to do with view visibility — they are project-wide data, not view-specific settings. Changing a type parameter updates the value everywhere in the project, across all views. Answer C is wrong because the tag family is irrelevant to the scope of the change; all six doors share the same tag family, but they belong to two different door types, so they won't all display the same new value. Your study tip: memorize the mantra — type parameters change the type, instance parameters change the individual. This rule applies universally across families, tags, and schedules in Revit.

Question 9

Three furniture instances use the same family type. Unit Cost is a type parameter and Finish Code is an instance parameter. From the first instance, a user changes Unit Cost from $450 to $500 through Edit Type and changes Finish Code from F1 to F2 in the Properties palette.

Which statement correctly describes the final data for the three instances?

  1. All three show a $500 Unit Cost, but only the first instance has Finish Code F2 (correct answer)
  2. Only the first shows a $500 Unit Cost, but all three have Finish Code F2
  3. All three show a $500 Unit Cost and all three have Finish Code F2
  4. Only the first shows a $500 Unit Cost and only the first has Finish Code F2
Explanation: Whenever you see a Revit question about parameters changing across multiple instances, your first instinct should be to identify whether each parameter is a type parameter or an instance parameter — because these behave in fundamentally opposite ways. A type parameter is shared across every instance that uses the same family type. When you click "Edit Type" and modify a type parameter, you're editing the type definition itself, so every instance of that type inherits the change simultaneously. A instance parameter, by contrast, belongs only to that specific placed element. Changing it in the Properties palette affects only the selected instance, leaving all others untouched. In this scenario, Unit Cost is a type parameter, so editing it to $500 via Edit Type propagates to all three furniture instances — they all now show $500. Finish Code is an instance parameter, so changing it from F1 to F2 on the first instance affects only that one element; the other two still carry F1. This makes A the correct answer: all three show $500 Unit Cost, but only the first instance has Finish Code F2. B is wrong because it reverses the logic — it treats the type parameter as instance-only and the instance parameter as global. C is wrong because it assumes both changes propagate universally, ignoring that instance parameters are local. D is wrong because it treats the type parameter as if it only affects the selected instance, which is precisely what instance parameters do, not type parameters. A reliable memory trick: Type = Team change, Instance = Individual change. On the Revit exam, this distinction appears frequently, so always check whether a parameter lives at the type or instance level before predicting how edits will spread.

Question 10

A door family has Fire Rating defined as a type parameter and Comments defined as an instance parameter. Two doors use the same type. A user selects the first door, changes Fire Rating through Edit Type, and then changes Comments in the Properties palette.

What is the resulting scope of the two changes?

  1. Both changes apply only to the selected door because it initiated both edits
  2. Both changes apply to both doors because they share the same family type
  3. Fire Rating changes for both doors, while Comments changes only for the selected door (correct answer)
  4. Fire Rating changes only for the selected door, while Comments changes for both doors
Explanation: Whenever you see a Revit question involving parameter changes, the first thing to ask yourself is: Is this a type parameter or an instance parameter? This distinction controls exactly how far a change will ripple through your project. In Revit, a type parameter is shared by every element that uses the same family type. When you open Edit Type and modify a value there, you are editing the type definition itself — so every door, wall, or window of that type updates simultaneously. A Fire Rating stored as a type parameter means both doors inherit the change the moment you confirm it. An instance parameter, by contrast, belongs only to the individual element you have selected. Changing Comments in the Properties palette affects that one door and leaves all others untouched. That logic confirms answer C: Fire Rating updates for both doors (type-level change), while Comments updates only for the selected door (instance-level change). Answer A is wrong because it incorrectly treats both parameters as instance-scoped — the act of selecting a door does not limit a type parameter edit to that door alone. Answer B is wrong for the opposite reason: it incorrectly treats both parameters as type-scoped, ignoring that Comments is an instance parameter. Answer D perfectly reverses the correct logic, swapping which parameter is type-level and which is instance-level — a classic trap designed to catch students who confuse the two scopes. As a study tip, always check the parameter definition in the Family Editor (or notice whether a value appears in Edit Type vs. the Properties palette) to determine scope before predicting what will change.