December 15, 2025

Type vs Instance Parameters in Revit: When to Use Each (With Real Examples)

TL;DR

A Type parameter is shared by every instance of a family type — change it and every placed element of that type updates. An Instance parameter belongs to one element only. Catalogued product data (dimensions, model codes) goes Type. Placement-specific data (room numbers, marks, notes) goes Instance. Type formulas cannot reference Instance parameters — information flows one way: Type → Instance.

Key Takeaways

✓Type parameters are shared by every instance of a type — change one, all instances update.
✓Instance parameters belong to one placed element — change one, only that element updates.
✓Catalogued product data (dimensions, model codes, fire ratings) → Type.
✓Placement-specific data (room numbers, marks, site notes) → Instance.
✓Type parameter formulas cannot reference Instance parameters — flow is Type → Instance only.
✓The wrong scope choice corrupts schedules and breaks formula chains.
✓Decision test: does this value define the product, or the placement?

A Type parameter is shared by every instance of a family type. Change it — every door of that type updates. An Instance parameter belongs to one placed element. Change it — only that element updates.

That is the entire distinction. The difficulty is deciding which one to use for a given piece of data — and that decision has downstream consequences for formulas, schedules, and every family that depends on yours.

5 Real Scenarios With the Correct Answer

Door Width and Height

→ TYPE

Door widths and heights define the product. A 900 × 2100 mm door is a specific catalogued type. Every instance of that door must have the same dimensions — that is what makes them the same type. If Width were an Instance parameter, you could accidentally end up with an 800 mm door scheduled as the same type as a 900 mm door. That is a procurement error.

Room Number on a Furniture Tag

→ INSTANCE

Every desk is in a different room, so Room_Number must be editable per element. If it were a Type parameter, all desks of the same model would display the same room number — which is obviously wrong.

Manufacturer and Model Code

→ TYPE

The manufacturer and model code describe the product, not the placement. Every instance of a specific desk model has the same manufacturer and model code. Making these Instance parameters would mean filling them in manually for every element — creating inconsistency and extra data-entry work.

Comments and Mark Field

→ INSTANCE

Comments and Mark are element-specific identifiers.Mark is typically a unique tag per element in a schedule. Comments holds placement-specific notes. Both must vary per instance by definition.

Material Finish

→ IT DEPENDS

Use Type if the material defines the product specification. A “White laminate” finish is a different catalogued product from a “Walnut veneer” finish — they should be different types in the schedule.

Use Instance if the material is a site-specific variable — for example, a modular partition system where the finish is specified per room at the point of placement. The deciding question: does the finish go in the product schedule, or the site specification?

4 Common Mistakes from the Wrong Scope Choice

Instance parameter on a catalogued dimension — Width as Instance means every door in the project can have a different width while being scheduled as the same type. Procurement orders the wrong quantities.
Type parameter on a placement-specific field — Fire_Rating_Note as Type means you cannot update individual doors in different fire compartments without creating duplicate types for every variation.
Formula referencing wrong scope — Type parameter formulas cannot reference Instance parameters. The formula silently produces incorrect results with no error message. See why your Revit family formula isn't working for the full breakdown.
Schedules showing the wrong level of detail — If dimensions are Instance parameters, each row in your door schedule represents one placed door, not one door type. A project with 200 identical doors generates 200 rows.

How Parameter Scope Affects Formulas

The rule in Revit is directional. Information flows one way only:

Type parameter formulas → can only reference Type parameters Instance parameter formulas → can reference Type AND Instance parameters

Valid:

[Instance] Clear_Height = [Type] Nominal_Height - [Instance] Floor_Finish_Thickness

Invalid:

[Type] Label = IF([Instance] Is_Accessible, "ADA", "STD") ^ cannot reference Instance from a Type formula

This directionality affects nested formula chains. If any parameter in a chain is Instance, every formula that eventually references it must also be Instance.

The 30-second decision test

Answer these three questions in order when creating any new parameter:

1
Does this value define the product, or the placement?
Product definition → Type | Placement-specific → Instance
2
If I placed 50 of these elements, should they all share this value?
Yes → Type | No → Instance
3
Will this appear in a quantity schedule where each row = one type (not one element)?
Yes → Type | No → Instance

If all three answers conflict, the deciding factor is almost always Question 1 — product definition vs. placement data.

Go deeper

How parameter scope interacts with every formula type

IF statements, CSV lookups, Yes/No automation — all covered with worked examples. Ebook + Video Vault + Cheat Sheet. 40% off at $18.