Revit Shared Parameters and Schedules: When to Use Them and How to QA Your Model

Most Revit users meet shared parameters the hard way. You build a tag, point it at a custom field, and it works. Then a colleague opens the model, the tag reads “no value,” and nobody can explain why. Or you try to schedule a custom field across walls and doors at once, and Revit refuses to let you add it. The fix is almost always the same: the field needed to be a shared parameter, and it was not.

Shared parameters are one of the most practical skills a working BIM professional can own. They sit underneath tags, schedules, IFC exports, and any data you want to trust across a whole project. Get them right and your model becomes queryable and self-checking. Get them wrong and you spend afternoons hunting blank fields. This guide explains what shared parameters actually are, when you genuinely need them, and how to turn schedules into a quality-control tool that catches errors before the model leaves your office.

---

The Parameter Types in Revit, Ranked by Scope

Before you can decide when to use a shared parameter, you need a clear mental model of every parameter type Revit offers. They differ in two things: where they live and how far they reach.

Parameter type	Lives in	Scope	Can schedule	Can tag	Stable across files
Built-in	Revit itself	Everywhere	Yes	Yes	Yes
Family parameter	One family file	That family only	No (not directly)	No	N/A
Project parameter	One project file	Selected categories	Yes	No	No
Shared parameter	External .txt file	Anywhere you add it	Yes	Yes	Yes
Global parameter	One project file	Project-wide value	No	No	No

Built-in parameters ship with Revit. Width, Height, Area, Comments, Mark. You cannot delete them and they behave consistently in every file. Family parameters are private to a single family. They drive geometry and flex, but you cannot schedule or tag them at the project level. Project parameters are added to a project for chosen categories. They schedule fine but they live only in that one project, and they cannot be tagged. Global parameters hold a single project-wide value or a driving dimension. Shared parameters are the only type that can be both tagged and scheduled while staying identical across every family and project that uses them.

That last property is the whole point, so it deserves its own section.

What Actually Makes a Shared Parameter Different

A shared parameter is defined once in an external text file and identified by a GUID, a globally unique ID. When you load that parameter into a family, a project, or another family, every instance points back to the same GUID. Revit treats them as the same field, not as two fields that happen to share a name.

This is why a project parameter cannot be tagged and a shared parameter can. A tag is a separate family that reports a value from the element it labels. For the tag to find the value reliably, both the tag and the host element need to reference the exact same parameter definition. The GUID is that shared reference. Two project parameters named “Fire Rating” in two different families are unrelated as far as Revit is concerned. Two instances of one shared “Fire Rating” parameter are the same field everywhere.

The practical takeaways:

• If you want to tag a custom value, the field must be a shared parameter.
• If you want to schedule one custom field across multiple categories (walls and doors and rooms together), use a shared parameter so the column matches.
• If you want a field to survive being copied between projects and still map cleanly, use a shared parameter.

When You Genuinely Need Shared Parameters

Shared parameters are powerful, but they are not free. Each one adds a definition you have to manage. Reach for them when one of these is true:

1. You need to tag the value on a drawing. Custom fire ratings, acoustic ratings, manufacturer codes, asset IDs. Any custom data that appears in an annotation tag must be shared.
2. You need a multi-category schedule. A door and window schedule that lists a shared “Cost Code” column, or a multi-category schedule pulling a custom asset tag from every component.
3. You are exporting to IFC or COBie. Shared parameters map cleanly to IFC property sets and COBie fields. Random project parameters do not map predictably.
4. You work across multiple disciplines or firms. When structural, MEP, and architectural models all need a shared “Zone” or “Level Code” field, a single shared parameter file keeps them aligned.
5. You build content for a company library. Families authored with shared parameters slot into any project that loads the same definitions, with no rework.

If your project lives in one file, the data never appears in a tag, and you do not export structured data, a plain project parameter is often enough. Do not over-engineer a single-building schedule with a library-grade parameter system.

Creating a Shared Parameter File the Right Way

The shared parameter file is a simple .txt file, but it is the single source of truth for your whole standard. Treat it like one.

Step 1: Set the location before you create anything. Go to Manage, then Shared Parameters. Click Create and save the file somewhere central. On a real project this should be a network or cloud path that the whole team reads from, not a copy on your desktop. If everyone points at their own file, the GUIDs drift and tags break.

Step 2: Build parameter groups. Inside the dialog, create groups that mirror how you think about data: Identity, Fire and Acoustic, Cost, FM Asset, Coordination. Groups here are organizational only. They are not the same as the “group parameter under” category you pick when you load the parameter into a project.

Step 3: Add parameters with the right discipline and type. When you create a parameter, choose its discipline (Common, Structural, HVAC) and its data type (Text, Number, Length, Yes/No, Material). Pick the narrowest type that fits. A fire rating that should read “60” is a Number or Text field, not a Length. Once a parameter is created and used, changing its type means making a new parameter, so get this right the first time.

Step 4: Never let the file be edited casually. The moment a GUID is in use across families and projects, deleting or recreating it orphans every reference. Lock down who edits the file. Many firms keep it read-only and route changes through a BIM lead.

Loading Shared Parameters into Families and Projects

There are two paths, and the difference matters.

Into a project (for instance or type data on existing elements): Go to Manage, then Project Parameters, then Add. Choose “Shared parameter,” select it from the file, and pick the categories it applies to and whether it is Instance or Type. The parameter now schedules across those categories. It still cannot be tagged from here, because tagging needs the same definition inside the element’s family.

Into a family (so it can be tagged and travels with the content): Open the family, go to the Family Types dialog, add a parameter, choose “Shared parameter,” and select it. Load the family back into the project. Now the value can be tagged, scheduled, and exported, all pointing at the same GUID.

A common workflow combines both. Author the shared parameter into your families for tagging, and add the same shared parameter as a project parameter so legacy elements without it still appear in schedules.

Building Schedules That QA Your Model

Here is where shared parameters pay off twice. A schedule is not only a deliverable. It is the fastest model-checking tool Revit gives you, because it surfaces data the 3D view hides. The model can look perfect and still be full of missing or wrong information. A well-built schedule makes those gaps impossible to ignore.

The core technique is to schedule the fields you care about, then sort and filter so problems float to the top. Turn on “Itemize every instance” while checking, group when reporting. Use the Filter tab to show only rows that fail a rule, and add a calculated value or a conditional highlight to flag bad data in color.

The mindset shift is simple. Stop building schedules that only answer “how many.” Start building schedules that answer “what is wrong.”

Five QA Schedules Every BIM Pro Should Build

These five take minutes to set up and catch the errors that cause RFIs, failed exports, and embarrassing tag values on a printed sheet.

1. Missing-data check. Schedule a category with your critical shared parameters as columns. Add a Filter where the parameter “equals” blank, or build a calculated yes/no that flags empty fields. Every row that appears is an element missing required data.
2. Unplaced and orphan rooms. Schedule rooms with Area as a column and filter for Area “less than” a tiny value. Rooms that are unplaced or not enclosed report zero or near-zero area and jump out immediately.
3. Type consistency check. Schedule by Type with the parameters that should be identical within a type. Sorting by type name reveals where someone overrode a value at the instance level when they should not have.
4. Mark and ID duplicates. Schedule the Mark or a shared asset ID, sort by it, and itemize. Duplicates sit next to each other. Since Mark is meant to be unique per element, any neighbor match is an error.
5. Naming and code compliance. Schedule the fields that must follow a standard, like a level code or zone, and filter for values that do not match the expected pattern. This catches the free-text typos that break downstream coordination.

Keep these as a saved set of schedule views in your template. Drop them into any project and you have an instant health check.

Shared Parameters, IFC, and openBIM

If your work touches IFC, shared parameters become essential rather than optional. When you export to IFC, Revit maps parameters into IFC property sets. A shared parameter with a stable GUID maps predictably, which means the receiving software (Solibri, Navisworks, a client’s platform) sees consistent property names across every element and every export.

Project parameters can be mapped too, but the mapping is brittle. Rename a project parameter or open a different file and the export drifts. For any data that a downstream consumer relies on, define it as a shared parameter and document how it maps to your IFC property sets. This is also how COBie deliverables stay clean: the asset fields are shared parameters from the start, not values bolted on at handover.

Common Mistakes to Avoid

• Multiple shared parameter files floating around. The most common cause of broken tags. One file, one central location, read-only for the team.
• Recreating a parameter instead of loading the existing one. If you make a new “Fire Rating” with a new GUID, it will not match the tags or schedules that reference the original. Always load from the file, never retype the name.
• Choosing the wrong data type. A Length-type field that should hold a plain number will format with units you do not want and resist scheduling cleanly. Fix it before the parameter spreads.
• Instance versus type confusion. Decide whether a value belongs to every instance or to the type. A fire rating is usually a type property. An asset ID is an instance property. Getting this wrong forces painful rework later.
• Treating schedules as output only. If you never filter for blanks and errors, your schedules will happily report bad data as if it were fine. Build the QA views deliberately.

Best Practices Checklist

1. Keep exactly one shared parameter file in a central, read-only location, and route all changes through a BIM lead.
2. Define a parameter once and reuse the GUID everywhere. Never retype a name to recreate a field.
3. Use the narrowest data type that fits the value, and decide instance versus type before the parameter spreads.
4. Author tagging-critical fields into families, and mirror them as project parameters so legacy elements still schedule.
5. Map your important shared parameters to IFC property sets and document that mapping in your BIM Execution Plan.
6. Save a set of QA schedules (missing data, duplicates, zero-area rooms, type checks) in your project template and run them before every issue.
7. Review the shared parameter file at project start so the team is not inventing fields mid-project.

Where to Go From Here

Shared parameters are the quiet backbone of a trustworthy Revit model. They turn scattered custom data into fields you can tag, schedule, check, and export with confidence. The investment is small: one well-managed file, a handful of disciplined habits, and a set of QA schedules you reuse on every job. The payoff is a model that tells you when something is wrong instead of letting a blank tag reach a printed drawing.

If you want to build these workflows into real muscle memory, the Revit and BIM coordination courses at Archgyan Academy walk through parameters, schedules, and model checking on full project examples, taught from a working BIM coordinator’s chair. Start with the parameter file, build your five QA schedules, and you will already be ahead of most teams.