TL;DR
A type parameter changes every element of that type in the project at once; an instance parameter changes only the one you selected. The 30-second test: 'If I change this value, should every copy update?' Yes → type. No → instance. One more rule that catches everyone: a type parameter's formula cannot reference an instance parameter, so scope decisions constrain which formulas you can write.
Key Takeaways
- ✓Type parameters define the product; instance parameters define the placement.
- ✓Changing a type parameter updates every element of that type in the entire project — instantly.
- ✓The decision test: "Should every copy update together?" Yes → type. No → instance.
- ✓A type parameter formula cannot reference an instance parameter — plan scope before writing formulas.
- ✓Wrong scope corrupts schedules: instance-scoped catalog data multiplies rows and invites typos.
- ✓When both behaviors are needed, use paired parameters: a type default plus an instance override.
Every parameter in a Revit family asks you one quiet question at creation: type or instance? It looks like a checkbox. It is actually the most consequential decision in the family — it decides who controls the value, how schedules read it, and which formulas you are allowed to write. Choosing it by habit instead of on purpose is how families end up fighting their users.
What Each Scope Means
| Type parameter | Instance parameter | |
|---|---|---|
| Controls | Every element of the type | Only the selected element |
| Edited in | Type Properties dialog | Properties palette |
| Change ripples? | Project-wide, instantly | One element only |
| Typical data | Catalog dimensions, model numbers, materials | Mounting height, offsets, mark, comments |
| Mental model | What the product is | How this copy is placed |
The 30-Second Decision Test
Ask one question about the parameter:
A door's width belongs to the product — every “900 × 2100 Single Flush” should be exactly that size, so width is a type parameter. The same door's frame finish on level 3 might differ from level 1 — placement-specific, so instance.
Five Real Scenarios
| Parameter | Correct scope | Why |
|---|---|---|
| Door width | Type | Catalog dimension — defines the product |
| Sink mounting height | Instance | Varies room by room, code by code |
| Cabinet carcass material | Type | Specification data, must be uniform |
| Duct connector elevation | Instance | Depends on each placement |
| Manufacturer model number | Type | Identifies the product in schedules |
The Formula Rule Nobody Tells You
Scope also constrains your formulas: a type parameter's formula cannot reference an instance parameter. Revit blocks it because a type value must be one value for all copies, while an instance value differs per copy. The reverse works fine — instance formulas can read type parameters freely:
This is why scope planning comes before formula writing. If a calculated value must feed a type parameter, every input to that calculation must be type-scoped too.
Schedules: Where Wrong Scope Hurts Most
Schedules group by type. Catalog data stored as instance parameters means someone types the model number 200 times — and typo number 137 becomes a procurement error. Data that describes the product must live at type scope so it appears once, correctly, everywhere.
The Best of Both: Default + Override
When a value usually follows the type but occasionally needs a local exception, pair two parameters:
The IF pattern that powers this override switch is the subject of the conditional statements chapter, and the Yes/No toggle itself is covered in controlling Yes/No parameters.
Chapter 3 of 10
Choose the right scope on purpose, every time
The complete guide covers all 10 chapters with worked examples, HD Video Vault, and Cheat Sheet. 40% off at $18.