Shared vs. Project Parameters — Explain shared parameters vs project parameters (conceptual)

Historical Context & Motivation

Before Building Information Modeling (BIM) tools became standard, architects and designers managed project data through disconnected spreadsheets, CAD attribute tables, and manual annotation layers. Each drawing existed as an isolated document with no inherent awareness of material quantities, cost data, or spatial relationships. The emergence of parametric modeling in the late 1990s and early 2000s fundamentally changed this paradigm by embedding intelligence directly into building components. Rather than drawing lines that merely represent walls, designers began placing objects that carry data—dimensions, materials, fire ratings, and more—through parameters.

Autodesk Revit, first released in 2000, was built from the ground up around this parametric philosophy. However, as projects grew in complexity and firms needed to coordinate data across dozens of families, multiple projects, and large multi-disciplinary teams, it became clear that a single type of parameter could not serve every purpose. The distinction between shared parameters and project parameters arose from this practical need: some data must travel between files and appear in schedules and tags, while other data only matters within a single project context.

The central question that this lesson addresses is deceptively simple: when you need custom data in a Revit project, should you create a shared parameter or a project parameter? The answer depends on how far that data needs to travel—within a single project file, across multiple families, into schedules and tags, or even between separate project files entirely. Understanding this distinction is not merely a technical detail; it shapes how efficiently a design team can extract, coordinate, and communicate information throughout the lifecycle of a building.

Core Principles & Definitions

Before diving into the two parameter types, it helps to ground the discussion in Revit's data architecture. Every element you place in a Revit model—a wall, a door, a light fixture—is an instance of a family. Families carry built-in parameters (height, width, material) that Revit defines automatically, but real projects demand additional custom data fields. A gallery might need a "UV Protection Rating" on its glazing; a theater might track "Acoustic Absorption Coefficient" on wall panels. These custom fields are parameters you create yourself, and the scope you choose—shared or project—determines how that data behaves.

Visual Explanation — Parameter Scope Diagram

Notice the asymmetry in capabilities. The green checkmarks on the left column confirm that shared parameters—when loaded into a family—gain full visibility: they appear in the Family Editor, can be scheduled in any project that loads that family, and critically, they can drive tag labels on annotation views. The right column, representing project parameters, shows a more constrained picture. Project parameters are faster to set up (no external file needed), but they trade portability for convenience. If you are designing an exhibition space and need every lighting fixture to display its color temperature in a tag on your reflected ceiling plan, you must use a shared parameter. If you simply need an internal notes field to track which fixtures have been approved by the curator, a project parameter suffices.

How Parameters Work Under the Hood

Although Revit's parameter system is not fundamentally mathematical in the way a physics equation is, understanding the underlying mechanism clarifies why the two parameter types behave so differently. At its core, every Revit parameter is a key-value pair stored in a database table within the .rvt or .rfa file. The key identifies the parameter, and the value stores the data (a number, string, yes/no, etc.). The crucial difference lies in how the key is constructed.

Project Parameter Keys

A project parameter's key is an internal identifier generated within the .rvt file at the moment you create the parameter. This identifier is unique to that file. If you create a parameter called "Curator_Note" in Project A and another called "Curator_Note" in Project B, Revit treats them as entirely unrelated data fields—even though they share a human-readable name. There is no mechanism for Revit to recognize them as the same logical parameter because no external reference links them together.

Shared Parameter Keys (GUIDs)

A shared parameter's key is a GUID (Globally Unique Identifier) generated once and stored in the shared parameter file. This GUID follows the parameter everywhere it is loaded—into families, into projects, across machines, across offices. When Revit encounters element data tagged with a specific GUID, it can reliably match that data to the correct parameter definition. This is what enables tagging: a tag family references a GUID, and when placed on a view, it reads the value from any element that carries that same GUID.

The Parameter Resolution Chain

When Revit needs to display a parameter value—in a schedule, tag, or properties palette—it follows a resolution chain. For a project parameter, the chain is short: Revit looks in the project's internal database for any element of the assigned category and reads the stored value. For a shared parameter, the chain can begin in the family definition (where a default value may be embedded), then be overridden at the project level when the family is loaded. This layered resolution is what gives shared parameters their flexibility: a family author can set sensible defaults, and the project team can override them without breaking the parameter's identity.

Detailed Classification & Workflow Paths

Choosing between shared and project parameters is a workflow decision that depends on data visibility, portability needs, and team coordination. The following diagram maps the decision process visually, and the table beneath it provides a feature-by-feature comparison.

Worked Example — Creating and Using Both Parameter Types

Imagine you are designing a contemporary art gallery in Revit. The gallery has custom display panels (modeled as a wall-based family) and you need two pieces of custom data: a "Panel_Finish" field that must appear in annotation tags on your elevation drawings, and an "Internal_Cost_Code" that only the project manager needs to see in a schedule.

Strengths, Limitations, and Trade-Offs

Neither parameter type is inherently superior; each serves a distinct purpose in the BIM workflow. The trade-offs center on a balance between convenience and capability. Project parameters are quick to create and require no external file management, making them ideal for ad-hoc, project-specific data. Shared parameters demand upfront planning—maintaining the .txt file, coordinating it across team members, and deciding at the family level which parameters to embed—but they unlock tagging, multi-project consistency, and robust data export.

Connection to Advanced Theory — Global Parameters & Dynamo

The shared-versus-project parameter distinction is foundational, but Revit's parameter ecosystem extends further. Understanding where these two types sit within the broader hierarchy prepares you for more advanced data-management strategies, particularly as projects scale toward computational design and facility management workflows.

As you advance, you will encounter Global Parameters, introduced in Revit 2017, which allow a single value to drive dimensions and constraints across an entire project—imagine setting one "Gallery_Ceiling_Height" value that automatically adjusts every room in the model. These are project-scoped and cannot be shared, but they provide powerful project-wide control that neither shared nor standard project parameters offer. Beyond Revit's native interface, Dynamo (Revit's visual programming environment) and the Revit API can read and write both shared and project parameters programmatically, enabling automated data workflows—such as populating hundreds of shared parameter values from a spreadsheet or validating that every element in a model has required COBie data before export.

Practice Problems

Lesson Summary