#02 | Instance vs. Type Parameters in Revit: The Choice That Determines Your Project's Fate

The Strategic Crossroads

Every time you create a new parameter in the Family Editor, you face a dilemma: Type or Instance? Many modelers choose instinctively, without realizing that this single checkmark will radically change how that object is managed, computed, and modified within a BIM project.

Control or Flexibility?

Choosing between Instance and Type is not just a technical matter; it's a BIM Management decision. On one hand, we have the strength of standardization (the Type), and on the other, the freedom of adaptation (the Instance). Making the wrong choice means condemning anyone who uses your file to two unfortunate fates: ending up with a Project Browser cluttered with hundreds of useless types, or completely losing control over quantities during the scheduling phase.

In this second installment of "Inside the Files," we will see how to make informed decisions, analyzing the advantages of both solutions and discovering why, sometimes, excessive flexibility can become the worst enemy of a professional model.

The Power of Standard: Why "Type" Wins Hands Down

Let's take one of the free families available in the Marketplace as an example: the Kitchen Table with Chairs.

In this case, choosing the Type Parameter is mandatory. Why? Because a manufacturer doesn't sell "a table as long as you want," but rather specific models:

• Type A: 140x80 cm (4 chairs)
• Type B: 180x90 cm (6 chairs)
• Type C: 220x100 cm (8 chairs)

If you used Instance parameters, the user could lengthen the table by 2 millimeters or add half a chair. The result? A schedule in the project with 50 different rows for the exact same product. By using Type, you ensure that every modification is reflected across all occurrences in the project, maintaining data integrity and design consistency.

When does Instance save our lives instead?

Instance comes into play when the object needs to adapt to the specific context in which it is placed, without generating a new "item number" each time.

A concrete example is the Home Office Desk 02, one of the free families from the Marketplace.

A home office desk does not have universal measurements: it must adapt to the room, the corner, the person using it. For this reason, the length, depth, and height of the top are all Instance parameters — each element placed in the project can have its own dimensions, without creating a new Type.

The same applies to the side supports and the drawer: its dimensions are parameterized, as is its opening, defined by a numerical value in centimeters. In a villa with multiple study rooms, you might have three identical desks in Type but with different drawer openings, because each user has their own needs — and the model manages them all, without multiplying the Types.

Even the materials — top, drawer, legs — are Instance parameters: same family, different finishes for different rooms, all under control.

The other side of the coin: Schedules and Data Management

Choosing between Type and Instance not only affects the graphics but determines how you extract data from the model. This is where a wrong choice comes at a high price, and the schedule doesn't lie.

Imagine you used Instance parameters for the dimensions of the kitchen table—the one we saw earlier. In the project, you have 8 tables, all conceptually the same, but someone changed the length by 5mm, someone else changed the depth "just to make it fit." The result in your schedule:

Family	Length	Depth	Quantity
Kitchen Table	140 cm	80 cm	3
Kitchen Table	140 cm	82 cm	1
Kitchen Table	141 cm	80 cm	2
Kitchen Table	140 cm	79 cm	2

 

Four rows for the same product. In a real project, with dozens of families, this scenario multiplies — and material calculations become unreliable.

With the Type parameter, on the other hand, that variant either exists or it doesn't: no one can "lengthen by 5mm" without consciously creating a new Type, and the schedule remains clean and computable.

With the desk, conversely, Instance is the right choice: variations are intentional, expected, and in the schedule, you can still group or filter them by Type, separating the product logic from placement customization.

Inside the Files tip:

Use the Instance parameter for everything that is variable "in the field" (adaptive dimensions, contextual materials, adjustable openings, construction tracking codes, ...). Use the Type for everything that defines the object's identity (fixed catalog dimensions, standard materials, links to technical data sheets, ...).

Conclusion: Finding the balance

There is no universal rule, but there is a strategy: always ask yourself how the end user will need to manage that object. A family that is too rigid (only Types) is frustrating; one that is too free (only Instances) is dangerous. The secret to a professional family, like those you find in our Marketplace, lies precisely in balancing these two aspects.

If this article has piqued your interest, I invite you to test the difference by downloading the Revit Families I showed you, which you can find among the free products 😉