Revit Parameters are not all the same — and confusing them comes at a cost

You have loaded a family into the project. You open the Schedule, search for the field you need — width, material, product code — and it's not there. Or, you changed a value in a family, expecting everything in the project to change, but nothing happened. Or, you created a parameter in the Family Editor, convinced you could tag it in plan, and Revit told you no.

These are not bugs. They are the consequence of a very common misunderstanding: in Revit, the word "parameter" does not identify just one object. It identifies six. And each of these six objects has a different scope, a different position within the system, and different rules regarding what it can and cannot do.

Understanding the difference is not an academic exercise. It is the skill that prevents you from building families that seem to work in the Editor but break in the project.

The (parameter) map comes first

Before diving into the details, it is helpful to have a mental map. The six types of parameters are not six equivalent objects placed in a row — they are distributed across three levels of scope.

Family Level — they exist and operate within the .rfa file:

• Family Parameters
• Instance Parameters
• Type Parameters

Project Level — they exist and operate within the .rvt file:

• Project Parameters
• Global Parameters

Cross-level — they exist outside both, in an external .txt file:

• Shared Parameters

This map is the common thread. Whenever you ask yourself, "Why doesn't this parameter appear there?", the answer is almost always that it is in the wrong scope.

1. Family Parameters — the internal engine

Family Parameters are the parameters defined in the Family Editor to control the geometry, visibility, and behavior of the family itself. They do not leave the .rfa file — they are internal, local, private.

You can use them to build complex geometric relationships: drawer height that depends on the total height of the piece of furniture, panel thickness that scales with width, visibility of a component that turns on or off based on a boolean value. All of this works perfectly in the Editor.

The limitation kicks in when you load the family into the project: Family Parameters do not appear in Schedules, cannot be tagged in plan, and are not accessible from the outside. They are the engine under the hood — they make everything run, but the project user does not see or touch them.

When this limitation becomes a problem, the solution is called a Shared Parameter — but we will get to that in a moment.

2. Instance Parameters — controlled flexibility

Instance Parameters are a subset of family parameters — those that the user can modify after inserting the family into the project, instance by instance.

You insert ten chairs of the same type into a project: with an Instance Parameter, you can give each one a different width without creating ten distinct types. The value lives in the instance, not the type. Each element is independent of the others.

This makes them the right tool whenever you have variables that change on a case-by-case basis — adaptive dimensions, materials specific to a single element, distances that depend on the installation context.

The downside: if you have a value that must be identical and guaranteed for all elements of a certain configuration, the Instance Parameter is not the right choice. A distracted user can modify it on a single instance and break the consistency of the model without noticing.

If you want to delve into the logic of choosing between Instance and Type Parameters in the Family Editor, the ITF #02 article goes into detail with practical examples on the Marketplace.

3. Type Parameters — the guaranteed standard

Type Parameters define values at the type level, not the instance level. All elements that share the same type share the same value — without exception.

If you have a window with a width of 900mm defined as a Type Parameter, every window of that type in the entire project is 900mm wide. To change the width, you must create a new type. You cannot modify it on a single instance — Revit will not allow it.

This rigidity is exactly its strength. Type Parameters are the tool with which you build catalogs: each row of the catalog is a type, and each type has defined and immutable values. A 60x60 cabinet, an 80x60, a 100x60 — three types, three guaranteed configurations. No margin for human error.

The choice between Instance and Type is not technical — it is design-based. It depends on what you want to remain flexible and what you want to keep under control.

4. Project Parameters — custom metadata for the project

Leaving the Family Editor and entering the project, the logic changes. Project Parameters do not control a family's geometry — they add information to categories of elements already existing in the model.

Do you want to classify all doors in the project by building sector? Do you want to add a "Supplier" field to windows? Do you want to track the installation phase for each category of MEP system? Project Parameters are the tool. They are created from Manage > Project Parameters, assigned to one or more categories, and appear in the properties of all elements of that category in the current project.

The limitation is the scope: they exist only in that .rvt file. If you open another project, they aren't there. They do not transfer between files, they are not shared between teams — they are tied to the project like foundations are tied to the building.

Another limitation: they can appear in Schedules, but they cannot be tagged in plan. For tagging, you need a Shared Parameter.

5. Global Parameters — project rules

Global Parameters are parameters that govern the project from above. They do not belong to a single element or category — they belong to the entire project.

The classic use: you define a floor-to-floor height as a Global Parameter — 3200mm. Then, you link level dimensions, stairwell heights, and railing families to that value. If the floor-to-floor height changes, you update one single value and the entire project adjusts.

The difference from other parameters is conceptual rather than technical. A Global Parameter does not describe an element — it governs a relationship. It establishes a rule that applies to the entire project, regardless of how many elements participate in it.

They live in the .rvt file and are managed from Manage > Global Parameters. Like Project Parameters, they do not leave the project — but unlike them, they are not designed to schedule information: they are designed to maintain model consistency when design rules change.

6. Shared Parameters — the bridge between worlds

Shared Parameters are the only type of parameter that exists outside of any Revit file. They are defined in an external .txt file — the shared parameter file — and from there, they can be imported into different families and different projects.

This makes them the right tool for all cases where information needs to move: parameters that must appear in both the Family Editor and project Schedules, fields that must be tagged in plan, and data that must be consistent across multiple families of the same type distributed over several .rvt files.

A practical example: you create a piece of furniture family and want the "Product Code" field to be taggable in plan and schedulable in the bill of quantities. A Family Parameter cannot be tagged. A Project Parameter cannot be shared between families. The solution is to define "Product Code" as a Shared Parameter in the .txt file, and import it into the family and the project. From that moment, the same parameter — with the same identity — exists in both contexts and keeps them in sync.

The cost of this system is management: the .txt file must exist, be accessible, and be maintained. In a structured team, this becomes an explicit responsibility — someone must be the keeper of that file.

Comparison Table

The BIM Culture Tip

When you create a parameter, ask yourself first where it needs to live — not what it should be called.

The scope determines everything: if the parameter needs to leave the family and become information in the project, you need a Shared Parameter. If it must guarantee consistency between variants of the same object, you need a Type. If it must adapt to every installation context, you need an Instance. If it must govern a relationship that applies to the entire project, you need a Global.

The name comes after. The scope is the decision.

---

The six types of parameters in Revit are not six different ways of doing the same thing. They are six tools with distinct functions, operating at different levels of the BIM system. Confusing them produces fragile families, inconsistent models, and Schedules that do not show what they should.

The good news is that the logic is readable: once you are clear on the concept of scope — where the parameter lives and how far it can reach — choices become simpler and almost mandatory.

If you want to delve into how these logics translate concretely into building Families, the articles in the Inside the Files series on Factory268 go into operational detail, with examples taken directly from the Marketplace files.