Shared Parameters — Add shared parameters to families for consistent scheduling/tagging (intro) - Autodesk Revit

SECTION 1

Historical Context & Motivation

When Revit introduced its parametric family system, designers gained the ability to embed custom information—finish codes, manufacturer names, artwork dimensions—directly into the objects they modeled. Yet a frustrating limitation quickly surfaced: a parameter you created inside one family could not be read by schedules or tags in the wider project. Revit treated that data as a private note, visible only inside the component that authored it. For visual artists and designers building custom furniture, signage, or installation elements, this meant painstaking, error-prone re-entry of the same information over and over.

The shared parameter was Autodesk's answer to this fragmentation. By storing a parameter's definition in an external text file with a permanent unique identifier, Revit could recognize the same parameter across many families and across the project itself, allowing information to surface cleanly in schedules and on tags.

2000 • Revit 1.0 Launches

Revit Technology Corporation releases the first parametric building modeler, introducing families with embedded parameters but no cross-family data sharing.

2002 • Autodesk Acquires Revit

Autodesk purchases the platform, accelerating development of a professional-grade parameter framework for large collaborative projects.

2004 • Shared Parameters Mature

The shared parameter file (.txt) and GUID-based definitions become the standard method for exposing custom family data to schedules and tags.

2010s • BIM Standards Adopt Them

National BIM standards and office templates begin distributing curated shared parameter files to enforce consistent data across firms.

The gap this concept closes is deceptively simple to state yet essential in practice: how do you make a custom piece of information—one you invented for your own components—behave like a first-class citizen that Revit can schedule, tag, and report anywhere in the model?

SECTION 2

Core Principles & Definitions

To understand shared parameters, you must first distinguish them from the two other parameter types Revit offers. A family parameter lives inside a single family and controls its geometry or behavior, but it cannot appear in schedules or tags. A project parameter can be scheduled but exists only within one project and cannot be tagged. A shared parameter alone can do both—and travel between projects—because its identity is anchored in an external file.

External Definition File

A plain .txt file stores each parameter's name, data type, and a permanent GUID (globally unique identifier).

GUID Identity

The GUID—not the name—is what Revit matches on, so two parameters named identically but with different GUIDs are treated as unrelated.

Schedulable & Taggable

Only shared parameters can simultaneously appear as schedule columns and be read by tag families.

Portable Consistency

Because the definition is external, the same parameter can be loaded into countless families and projects with guaranteed matching data.

✦

KEY TAKEAWAY

Think of a shared parameter file like the catalog raisonné behind an artist's body of work. Two paintings might both be titled "Untitled," but each carries a unique catalog number that unambiguously identifies it across galleries, exhibitions, and archives. The GUID is that catalog number: it lets Revit recognize the same piece of data no matter which family or project it appears in, so your custom information never gets confused with a look-alike.

SECTION 3

Visual Explanation

The diagram below traces the flow of a shared parameter from its external definition file into a family, and finally out to both a schedule and a tag. Notice that the shared parameter file sits outside every project, acting as the single source of truth that all consumers reference.

The shared parameter file defines Finish_Code once. That definition is loaded into the family, given a value, and then flows to both the schedule column and the tag—because all three reference the same GUID.

Because the schedule and the tag both read the identical GUID, the value "OAK-03" you type into one chair will display consistently everywhere—no manual copying, no risk of a mismatched column reading a different, look-alike parameter.

SECTION 4

How It Works Under the Hood

A shared parameter is not defined by a formula but by a structured record inside its text file. Understanding that record clarifies why the mechanism is so reliable. Each parameter entry contains a GUID, a name, a data type (such as Text, Length, or Yes/No), and a group assignment. The GUID is a 128-bit hexadecimal value that is statistically guaranteed to be unique.

GUID STRUCTURE

GUID = XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX

32 hexadecimal digits (128 bits) grouped 8-4-4-4-12. Each X is one of 16 values, giving 16³² ≈ 3.4 × 10³⁸ possible identifiers—so accidental collision is effectively impossible.

When Revit loads a family into a project, or builds a schedule, it performs a matching operation. Rather than comparing parameter names as text, it compares GUIDs. This is the crucial behavior: the match key is the GUID, not the human-readable label.

MATCHING RULE

scheduled(P) ⟺ GUID(P_family) = GUID(P_project)

A parameter P is correctly scheduled or tagged only when the GUID stored in the family exactly equals the GUID Revit knows in the project. If the GUIDs differ—even with identical names—the data will not connect.

⚠

Common Pitfall

If two team members each create a parameter named "Finish_Code" from separate shared parameter files, the GUIDs differ and the values will not combine into one schedule column. Always distribute a single, shared .txt file across the team.

SECTION 5

Classifying Parameter Types

Choosing the right parameter type is a design decision with real workflow consequences. The table below classifies the three principal options by capability, clarifying exactly when a shared parameter is required.

Type	Can Schedule?	Can Tag?	Portable?
Family Parameter	No	No	Within one family only
Project Parameter	Yes	No	One project only
Shared Parameter	Yes	Yes	Across families & projects

Capability comparison of Revit's three parameter types

The pattern is clear: if your custom data must appear in both a schedule and a tag, or must move between projects, a shared parameter is the only correct choice. For purely geometric controls that never leave the family—say, a dimension that drives a leg thickness—a family parameter remains lighter and appropriate.

✓ Instance vs. Type: A shared parameter can be assigned as an instance parameter (varies per placed object) or a type parameter (shared by all objects of that type).
✓ Parameter Group: When binding, you choose a category grouping (e.g., Identity Data) that controls where it appears in the Properties palette.
✓ Data Type is Permanent: Once a shared parameter's data type is set in the file, it cannot be changed—only replaced by a new definition.

SECTION 6

Worked Example: Tagging Custom Furniture

Suppose you are designing a gallery installation with several custom bench families. You want each bench to carry a "Finish_Code" that appears both in a finish schedule and on plan tags. Let us walk through creating and applying the shared parameter.

Creating a Schedulable, Taggable Finish Code

1
Step 1 — Create the Shared Parameter File

In Revit, go to Manage ▸ Shared Parameters ▸ Create. Save a new text file, for example Studio_Params.txt, to a network location the whole team can access.

A single source-of-truth .txt file now exists.
2
Step 2 — Define the Parameter

Under a new group "Furniture," add a parameter named Finish_Code with the discipline Common and data type Text. Revit automatically assigns a GUID.

Finish_Code (TEXT) with GUID is registered.
3
Step 3 — Load Into the Family

Open the bench family. Go to Family Types ▸ Add Parameter ▸ Shared Parameter, browse to Finish_Code, and assign it as an Instance parameter under Identity Data.

The family now hosts the shared parameter.
4
Step 4 — Assign a Value and Load Into Project

Enter OAK-03 as the value, then load the family into your project. Because the GUID matches, Revit recognizes the parameter project-wide.

OAK-03 is now available to schedules and tags.
5
Step 5 — Schedule and Tag

Create a Furniture Schedule and add Finish_Code as a column; it appears in the available fields list. Then use a tag family that reads Finish_Code to label each bench in plan.

Value displays identically in schedule and tag.

The payoff: change the value on one bench instance and both its tag and its schedule row update automatically, since they are all reading the same GUID-anchored parameter.

SECTION 7

Strengths and Limitations

Shared parameters are powerful, but they carry administrative overhead. Weighing their advantages against their constraints helps you decide when the investment is justified.

Strengths	Limitations
Data flows to both schedules and tags	Requires managing an external file carefully
Portable across families and projects	Lost or renamed file breaks the workflow
GUID prevents accidental data mismatch	Data type cannot be edited after creation
Supports firm-wide standardization	Duplicate definitions cause silent split columns

Trade-offs of using shared parameters

✦

CONTEXT

In a professional BIM workflow, shared parameters function like a shared color palette in a design system. Individual designers may work on separate screens, but because they all pull hex values from one master palette file, the brand stays consistent everywhere. Abandon that master file and each person improvises their own "blue"—and the coherence collapses. Shared parameters keep everyone drawing from the same definition.

SECTION 8

Connection to Advanced Practice

As projects scale, teams move beyond hand-managed text files toward more robust data frameworks. Two important successors build directly on shared parameters.

Shared Parameter (Intro)	Advanced Approach
Manually maintained .txt file	Project Standards Manager: centralized governance across models
Loaded family-by-family	Shared Parameter Service / Autodesk Parameters: cloud-hosted definitions
Values entered by hand	Dynamo / API automation: bulk population and validation

From intro shared parameters to enterprise data management

Each advanced method still rests on the same GUID-based identity you learned here. Mastering the intro concept—why the GUID matters and how data flows to schedules and tags—gives you the conceptual foundation to adopt cloud parameters and scripted workflows without confusion later.

SECTION 9

Practice Problems

Question 1: CONCEPTUAL

Why can a family parameter never appear as a column in a project schedule, while a shared parameter can?

Show answer

A family parameter's definition lives entirely inside a single family and has no identity recognized by the wider project, so schedules have nothing to match against. A shared parameter, by contrast, is defined in an external file with a permanent GUID that both the family and the project can reference. Because the schedule matches on that GUID, it can pull the parameter's value into a column. This external, GUID-anchored identity is precisely what makes scheduling and tagging possible.

Question 2: BASIC CALCULATION

A GUID contains 32 hexadecimal digits. How many distinct values can a single hexadecimal digit represent, and roughly how many total GUIDs are possible?

Show answer

Each hexadecimal digit represents one of 16 values (0–9 and A–F). With 32 such digits, the total number of possible GUIDs is 16³², which equals 2¹²⁸ ≈ 3.4 × 10³⁸. This astronomically large space is why accidental GUID collisions are effectively impossible, guaranteeing that each parameter definition stays unique.

Question 3: INTERMEDIATE

Two designers each create a shared parameter named "Finish_Code" but from two different .txt files. They load their families into one project. What happens in the schedule, and why?

Show answer

The schedule will show two separate "Finish_Code" columns—or fail to combine the values—because the two parameters have different GUIDs. Revit matches on the GUID, not the name, so identical labels do not merge the data. This is a common silent error that fragments what should be one unified column. The fix is to distribute a single shared parameter file so both designers pull the same GUID-backed definition.

Question 4: APPLIED

You are producing an exhibition plan where each custom pedestal must display a material code on a plan tag and also list that code in a materials schedule. Outline the parameter type you would use and the key steps.

Show answer

Because the data must appear on both a tag and in a schedule, only a shared parameter will work. Create or open a shared parameter file, define a Text parameter such as "Material_Code," and load it into the pedestal family as an Instance parameter under Identity Data. Assign each pedestal its value, then load the family into the project. Finally, add Material_Code as a schedule column and use a tag family that reads it, ensuring both consumers reference the same GUID.

Question 5: CRITICAL THINKING

A firm wants every project to report the same set of custom sustainability metrics on furniture. Argue why shared parameters alone may be insufficient at scale, and what safeguards would strengthen the workflow.

Show answer

Shared parameters correctly guarantee data consistency through GUIDs, but at firm scale the external .txt file becomes a single point of failure—if it is copied, edited, or lost, teams may unknowingly branch definitions and split their data. Reliance on manual value entry also invites incomplete or inconsistent reporting. Strengthening the workflow means centralizing the file through a governance tool or cloud-hosted parameter service, locking the master file against edits, and using Dynamo or the API to bulk-populate and validate values. These safeguards preserve the GUID-based integrity while removing human error and file-management fragility.

SUMMARY

Summary

A shared parameter is the only Revit parameter type that can appear in both schedules and tags and travel between projects. Its identity is anchored not in its name but in a permanent GUID stored in an external .txt file. Revit matches parameters by GUID, which is why the same file must be shared across a team to avoid silently split columns and mismatched data.

To use one, you define the parameter in the file, load it into a family, assign a value, and then schedule or tag it—all three consumers reading the same GUID guarantee consistent display. Family parameters cannot schedule or tag; project parameters can schedule but not tag. As workflows scale, cloud parameter services and API automation build on this same GUID foundation, making the intro concept an essential stepping stone to professional BIM data management.