Parameters: which kind, and why

Revit has four kinds of parameter and they are not interchangeable. Choosing wrong is recoverable on day one and expensive on month six.

The comparison

Read the taggable row again. It's the reason shared parameters exist.

Family parameters

Created inside the Family Editor, in Family Types or when labelling a dimension. Choose type or instance at creation (you can change it later via the parameter's properties).

The test for which: would every one of these change together?

• Type — width, height, material, construction, fire rating, assembly code.
• Instance — sill height, mark, a per-element note, an asset tag.

Project parameters

Manage → Project Parameters → Add. Pick the categories it applies to and whether it's type or instance.

Useful for project-specific data you only need to schedule and filter on — a Design Review Status on walls, say. Two limits that catch people:

• Not taggable. If you need it on a drawing, it must be shared.
• Doesn't travel. New project, do it again. Transfer Project Standards does carry project parameters, which helps.

A view filter can only test parameters that exist on the categories you selected for the filter. If your parameter doesn't appear in the filter's rule dropdown, it's on the wrong categories.

Shared parameters

The important one.

A shared parameter is defined in an external text file with a stable GUID, then added either to families (in the Family Editor) or to a project (as a project parameter sourced from the shared file — the Shared Parameter button in the Add dialog).

Manage → Shared Parameters
  → Create… or Browse… to select the .txt
  → Groups: logical buckets ("Identity", "Analysis", "FM Data")
  → Parameters: name + discipline + type of parameter

The file itself is plain, tab-delimited, and readable:

*META	VERSION	MINVERSION
META	2	1
*GROUP	ID	NAME
GROUP	1	RB General
*PARAM	GUID	NAME	DATATYPE	DATACATEGORY	GROUP	VISIBLE	DESCRIPTION	USERMODIFIABLE
PARAM	9c2f4b7e-...	RB_AssetTag	TEXT		1	1		1

Matching is by GUID, not name. If you lose the shared parameter file and recreate a parameter with the same name, it gets a new GUID and Revit treats it as an entirely different parameter. Symptoms: tags go blank, and schedules show two columns with the same heading. There is no clean automated fix — you re-map by hand.

Keep the file in version control or a locked network location. Never let each person generate their own.

Type of parameter matters and can't be changed later. Text vs. Length vs. Number vs. Integer vs. Yes/No vs. Material vs. URL vs. Multiline Text. Picking Text for something numeric means you can't do arithmetic on it in a schedule.

Global parameters

Manage → Global Parameters. Project-wide values, and uniquely, they can drive dimensions.

Set a global Typical Corridor Width = 1500 mm, then assign it to the dimension between two corridor walls (select the dimension → the label dropdown → the global). Change the global and the walls move.

Also useful for driving other parameters: a global can be assigned as the value of an instance or type parameter via the small = button in Properties.

Formulas

Available on family parameters and in schedule calculated values.

• Case-sensitive names. Width ≠ width. Revit will tell you the name is unknown, which is a very small clue.
• Conditionals: if(Width > 900 mm, 2, 1). Nesting works: if(A, x, if(B, y, z)).
• Booleans are functions: and(a, b), or(a, b), not(a). Not &&.
• Comparison for Yes/No: just write the expression — Width > 400 mm — into a Yes/No parameter.
• Functions: abs round roundup rounddown sqrt exp log log10 sin cos tan asin acos atan pi().
• Trig takes degrees in the UI's unit context; be careful mixing.

Units in formulas

The rule: the formula's result must have the same unit type as the parameter.

Length / Length            → unitless number  ✔ into a Number parameter
Length * Length            → area             ✘ into a Length parameter
Area / Number              → area             ✘ into a Number parameter
Area / Number / 1 SF       → unitless number   ✔ (the standard workaround)

That last line is ugly and it is the accepted answer. In schedule calculated values you'll write it constantly.

Counting things

Shelf Count = roundup((Height - 100 mm) / Shelf Spacing) - 1

roundup on a unitless ratio is how nearly every "how many of these fit" parameter is written.

Driving visibility

A Yes/No parameter can be assigned to a solid's Visible property (select the solid → Properties → the small button next to Visible). Geometry appears and disappears based on a condition. This is the mechanism behind most sophisticated families — a single family that is a door with a vision panel when Has Vision Panel is true.

Reading parameters in code

Three ways, best first:

# Built-in enum — stable across versions and language packs
p = element.get_Parameter(DB.BuiltInParameter.ALL_MODEL_MARK)
 
# Shared parameter GUID — stable for your own data
p = element.get_Parameter(System.Guid("9c2f4b7e-...."))
 
# By name — convenient, breaks under localization
p = element.LookupParameter("Mark")

And the units trap, restated because it costs the most:

AsDouble() returns decimal feet for any length, regardless of project units. Set in feet, or use UnitUtils.ConvertToInternalUnits(3000, UnitTypeId.Millimeters). AsValueString() gives you the formatted display value instead.

A decision flowchart

1. Does it need to appear on a drawing via a tag? → Shared parameter.
2. Does it need to drive a dimension across the project? → Global parameter.
3. Is it intrinsic to one family's geometry or identity? → Family parameter (type if all instances share it, instance if not).
4. Is it project-specific data you only need to schedule and filter? → Project parameter — but consider making it shared anyway, because "we'll never need to tag it" ages badly.

When unsure: make it shared. The overhead is one entry in a text file.