Automate Revit Workflows with Shared Parameters
Rename Pro Team
Author, Rename Pro
Shared parameters are the connective tissue of a Revit project—the only fields that travel across families, schedule and tag, and survive export to IFC/COBie. Used well, they also become the engine for automated naming. Here's how to set them up and put them to work.
Project vs. Shared — Pick the Right One
| Project Parameter | Shared Parameter | |
|---|---|---|
| Stored | In the project file | External .txt + a permanent GUID |
| Reusable across files | No | Yes |
| Appears in tags | No | Yes |
| Appears in schedules | Yes | Yes |
| Survives copy between projects | Often breaks | Stays linked by GUID |
The deciding factor is the GUID. Revit identifies a shared parameter by its GUID, not its name—so the same field is recognized everywhere, and two same-named fields with different GUIDs are treated as strangers (the root cause of split schedule columns). If it must be tagged, scheduled, or exchanged, make it shared.
Set One Up (exact path)
- Create the definition:
Manage > Shared Parameters > Createa file (or open the team file), add a Group (e.g.,02_Identity Data), then a Parameter (e.g.,RP_Product_Code, type Text). - Bind it to categories:
Manage > Project Parameters > Add, choose Shared parameter, selectRP_Product_Code, tick the categories (e.g., Furniture), and choose Type or Instance. - Or build it into loadable families via the Family Editor's Family Types dialog so it ships with the content.
Type or Instance? It Decides What Can Drive a Name
When you bind the parameter, Revit asks Type or Instance. This isn't cosmetic: only type (and family) parameters are consistent across every placed element, so only those can drive a type name. An instance parameter varies element to element and can't. If that distinction is hazy, see Categories, Families, and Types. For naming, bind name-driving fields as Type.
Drive Names From It
Once the parameter carries data, use it as a name segment. In Rename Pro's Parameters panel, shared parameters show an open-circle (○) marker. Select yours, send it into the Name Rules panel, and position it in the formula.
Worked example. Furniture with a RP_Product_Code of HM-AERON and a category code FN, rule FN_<Family>_<Product Code>, produces FN_Chair_HM-AERON. Update the code, re-run, and the name follows.
One gotcha: Rename Pro lists shared parameters aggregated across all types in a category—if one type has the field, it shows for the category. A type missing that field yields a blank segment, so set a Default value on the rule if you want a fallback token instead of a gap.
Why Parameter-Driven Pays Off
- One source of truth: the value defines the name; a rename pass keeps name, schedule, and tag in lockstep.
- No transcription errors: removing typing removes a whole error class.
- Clean handover: GUID-stable metadata makes the COBie/6D transition far less painful.
Treat the type name as a derived view of your data: edit the shared values (in the family, project, or a schedule), then run a rename to regenerate. The visible name and the database never drift apart. None of this holds if the parameter file itself is a mess, so keep it disciplined—see How to Manage Your Revit Shared Parameters File Like a Pro.