Shared, Built-In, or Family? Making Sense of Revit Parameters

Every now and then, I come across posts trying to explain the different types of Revit parameters, and every time, I get a little annoyed. They’re often incomplete, inaccurate, or just plain wrong. Usually, they compare the following types, just as the Revit UI represents them:

• Project Parameters
• Family Parameters
• Type Parameters
• Shared Parameters
• Global Parameters

This is like comparing apples to oranges.

I’ll try to set the record straight and give a full, comprehensive picture of how parameters work. Of course, I might get something wrong—if you disagree with anything, I’m open to discussion. I won’t be covering the absolute basics, so a little prior knowledge is expected.

What Are Parameters?

First things first. Parameters are data containers that store information about the elements they’re attached to in a Revit project. Some parameters just hold metadata, while others actually affect the behavior or appearance of elements.

Now, here’s the kicker: only some of an element’s information is accessible through parameters. If you want the full picture, you’ll need the Revit API. There’s also a bit of confusion in Revit’s documentation and UI between “parameters” and “properties.” Most (but not all) parameters are accessible through properties—the UI representation of parameter names and values you see in the Properties palette. And just to make things more confusing, these properties aren’t the same as API properties, which is a whole other topic I’m not getting into right now.

But in the background, parameters are much more than just names and values—they’re part of a pretty complex system.

Two Main Types of Parameters

Revit parameters can be divided into two big groups:

1. Built-in (System) Parameters
2. User-Created Parameters

This article focuses mainly on user-created parameters because that’s where we, as users, have control. I’ll still mention built-in parameters here and there to compare them to user-created ones.

A Better Way to Classify Parameters

Instead of using the standard terms listed earlier, I think parameters should be classified based on these two criteria:

1. Where it’s defined: Project or Family
2. Is it shared or not?

Both aspects are needed to fully define a parameter, and the combinations give us 2×2=4 possibilities.

Parameters can either apply to an element instance or its type, but that doesn't really affect their behavior at all, aside from determining which panel you can find them on. However, for Built-In Parameters it gets a bit more interesting: some built-in parameters are bound to the family object itself. These parameters appear in the Family Categories and Parameters dialog or when you select the family by its ID in the project (you can even modify those here, without opening the family editor). Some even show up as read-only type parameters (e.g., OmniClass parameters).

1. Project or Family

Project Parameters are created in the project environment. They’re bound to selected categories, so every element in those categories gets the parameter. These are always available in category-specific and multi-category schedules or filters, because their definitions are unique to the project. Their instance / type binding is also consistent across the project.

The downside? Project parameters don’t show up in the family editor. That means they can’t control family behavior, drive geometry, or anything like that. But on the flip side, project parameters are the only way to attach parameters to system families (like walls).

Family Parameters are created in the family editor and are specific to that family. When you load the family into a project, the parameter comes along for the ride, but only accessible if the element is selected. These parameters can control geometry, visibility, materials, nested families—you name it. Instance / type binding is family specific.

However, family parameters don’t show up in schedules by default because they’re unique to the family, not the project. That lack of uniqueness makes them unidentifiable at the project level.

Built-In Parameters don’t fit neatly into these categories. Some act like project parameters (e.g., Type Mark), while others behave like category dependent family parameters (e.g., Width and Height for doors). So, the project/family distinction isn’t always clear-cut for built-ins.

2. Shared or Not

Things get a bit more complicated when you make any of the above parameter types a shared parameter. Shared parameters allow the same definition to be referenced across family and project environments. This gives user parameters a massive upgrade—they can now be tagged (used in labels), and consistently scheduled. In short, the shared option lets user-created parameters behave more like built-ins.

For example, say you create a shared parameter in a family to control geometry and load that family into a project. If you later decide to tag that parameter in the project, you’ll be able to because the shared definition is consistent across both contexts.

That’s still not everything. If you dig beyond the UI, there are some extra goodies hidden in the shared parameter file. For example, you can make your shared parameters invisible (or even conditionally visible based on whether their value exists). You can also "lock" them in the UI to make them read-only—though ironically, they’ll still be editable through the API!

However, shared parameters come with some quirks and side effects you need to know about:

When a shared parameter is introduced to a project—whether as a shared project parameter, through a family, or via a tag—it gets "burned" into the project. Its GUID (Globally Unique Identifier), name, data type, discipline, and description are set in stone for that project. If you later update the shared parameter file (keeping the GUID but changing the definition), the project will still use the original version. The original "Shared Parameter Element" remains in the project even after all related families and project parameters are removed. Be cautious when manually deleting such shared parameter elements from your project, as it can even break families.

Naming and Description Changes If the name or description changes in the shared parameter file, and that new definition is used in subsequent families, things can get messy. The project’s older definition takes precedence. For example:

• You load a family into a project where the parameter already exists but with a different name. Once loaded, the family’s parameter takes on the project’s name instead of keeping its own. The original parameter definition in the project will even override the family definition, meaning opening the family in the project will show the older version.

Data Type Mismatches If the data type of a shared parameter is updated, Revit can’t resolve the conflict automatically. For example:

• A shared parameter was originally defined as a Number parameter, but you update it to be Length in the shared parameter file. If you try to load a family with the updated definition into the project, Revit will throw an error and refuse to load the family. Fixing this mismatch is possible, but it’s a headache requiring a lot of manual effort.

Shared Project and Family Parameters can have the following conflicts:

• Instance/Type Binding Conflicts If the same shared parameter exists as both a project parameter and a family parameter but with different bindings (e.g., one is instance-bound, and the other is type-bound), the family’s binding will override the project’s.
• Parameter Group Issues The default group for a shared parameter (e.g., Identity Data, Constraints) is set when it’s first introduced—whether in a family or as a project parameter. If you later load the same parameter into other families with a different group setting, the original group will always take precedence in the project, and modifies the family. If a shared parameter is in the wrong parameter group in your project, the only way to modify it is through the Project Parameters dialog. If the parameter isn’t already added as a project parameter, you’ll need to add it—even if only temporarily—to make the change.

What About Global Parameters?

Global parameters are a different beast altogether. They aren’t element parameters—they’re just named preset values for certain data types that can drive actual parameters or dimensions in a project.

Are There More?

There is actually one more parameter type that can appear on the Properties panel: the Schedule Key parameter. It’s similar to a standard parameter in that it is bound to a category (though only a single one) and can appear in schedules. However, it has some unique characteristics—it only supports text as a data type and serves a completely different purpose: to drive other instance parameters, acting as a kind of "soft type." Interestingly, it’s the only user parameter that behaves like a dropdown, allowing only predefined values, which is why it’s often misused.

Some people even consider Schedule and Tag Calculated Values as element parameters. However, since they are context-specific and not directly attached to the element, I don’t classify them as such.

Conclusion

Instance/type binding isn’t as important when it comes to behavior. And global parameters? They’re a whole different kind of animal and shouldn’t be confused with the rest.

Instead of lumping element parameters into inconsistent broad categories, it’s more meaningful to classify them based on their behavior:

• Built-in Parameters
• Project Parameters
• Shared Project Parameters
• Family Parameters
• Shared Family Parameters

Tip: this differentiation of parameters is already visible in Revit since version 2022, if you hover over any property you will see the following tooltip:

To summarize the differences explained earlier, see the following table:

For additional details please see RevitCat's blog post from 2016: https://revitcat.blogspot.com/2016/07/understanding-parameter-differences-in.html