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.

Before the theory, here is a walkthrough from our channel that puts a shared parameter somewhere most parameter guides skip: the title block, so consultant names and addresses print on every sheet in the set. It runs a little over five minutes, and its last ninety seconds settle a rule that quietly costs people whole afternoons.

---

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, though their displayed names follow the interface language, which is why a script that matches on a label breaks the moment someone runs Revit in another language. 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.

The phrase “pick the categories” in that first path hides a decision worth spelling out, because it is not always plural. For ordinary element data, one shared parameter across several categories is exactly what you want: a Cost Code applied to doors and windows together schedules as a single column. Sheet and project data is the exception, and the video below is blunt about it: pick one category, because more than one stops the field working. My own reading of why, which the video does not go into, is that Project Information sits in that same list but is a single record for the whole file rather than a set of elements, so it does not combine cleanly with an element category such as Sheets. Either way the symptom is the same, a field that displays on the drawing and refuses to accept a value, and the worked example below runs straight into it.

Worked Example: Putting Consultant Data on Every Sheet

Everything above is the theory. Here is the case that turns it into muscle memory, because it is the one almost every project hits in its first week: the title block needs to carry the structural consultant, the MEP consultant, their addresses, and whatever else the client’s drawing standard demands. None of that exists as a built-in Revit parameter. The video above works through it end to end, and the walkthrough below adds the office context a short recording does not have room for.

Labels are not text, and the difference decides how you edit

Open a title block family and you are looking at two kinds of writing that look identical on screen. Some of it is plain text you typed, which you can double-click and retype whenever you like. The rest is a label, which displays the value of a parameter and cannot be edited on the canvas at all. To change what a label shows you select it and click Edit Label, which opens a dialog listing the parameters available to the family on one side and the parameters currently in that label on the other.

That distinction matters more than it sounds. A consultant name typed as plain text is baked into the family. Change consultants and somebody has to open the family, retype it, reload it, and hope nobody is still working from the old version. A consultant name driven by a parameter changes from inside the project, by anyone, without opening a family at all. On a multi-building job with one title block and four consultant teams, that is the difference between a five-second edit and an afternoon.

Creating the parameter from inside the label dialog

The existing structural consultant label in the video is already parameter-driven, so the quickest route to an MEP equivalent is to copy that block and edit the copy. Clear the structural parameter out of the label, go looking for an MEP one, and it is not there, because nobody has made it yet.

You do not have to leave the dialog to fix that. Add a parameter, choose Shared parameter, and click Select to open the shared parameter file. If the file already exists you pick from it. If it does not, Create makes one, and you build your groups and parameter names inside it before coming back. This is the same file described earlier in this guide, and the same rules apply: one file, one central location, no casual edits once the definitions are in use.

Two decisions get made here and both are permanent in practice:

• The data type. A consultant name is a plain text parameter. An address is not, and the video creates it as multi-line text so it can hold three or four lines instead of one long run of characters. Changing a parameter’s type after it is in use means creating a new parameter, so decide before you click OK.
• Where it sits in the file. The recording keeps these in the Common group rather than filing them under HVAC, on the reasoning that the field belongs to the sheet rather than to a mechanical element. Sheet data is not discipline data. It describes the drawing, not the building.

Once the parameter exists it appears in the label list and you move it across into the label itself. You can type a sample value so the family shows something sensible while you draft, or leave it blank so an unfilled field is obvious on screen.

Load it into the project, then hit the wall

With the labels wired, the family goes back into the project. Load into Project, then overwrite the existing version, and the new consultant block appears on the sheet.

Then comes the moment that sends people to forums. The field is there. You click it, and nothing happens. No cursor, no editable box, no error message. The structural consultant field beside it works fine, which makes it feel like the family is broken.

It is not. This is the most useful diagnostic in the whole workflow, so it is worth stating plainly:

A label that displays but will not accept a value means the shared parameter exists in the family but has not been added to the project. The family knows the parameter. The project has never heard of it, so there is nothing to type into.

The structural field works because somebody already did the second half for that one. The MEP field does not because nobody has yet.

The project parameter, and the category rule that decides everything

The fix is Manage, then Project Parameters, then Add, choosing Shared parameter and selecting the one you just made. Straightforward, except for one setting that quietly decides how the field behaves for the rest of the project’s life: the category you assign it to.

Assigned to	Value is	Set from	Use it for
Project Information	One value for the whole project	Manage, then Project Information	Consultant names and addresses, client details, anything identical on every sheet
Sheets	A separate value per sheet	The sheet’s Properties palette	Drawn by, checked by, package name, anything that varies sheet to sheet

The video assigns the consultant fields to Project Information, because the same consultant belongs on every sheet, and notes that a field you want to vary sheet by sheet has to go the other way, onto the per-sheet category, where it surfaces in the sheet’s properties instead.

Then the rule that costs the most time when it is missed: select one category only. The video puts it flatly: ticking more than one does not give you a field that works in two places, it gives you a field that does not work properly at all. Not in the video, but worth carrying with you when you make the choice: Project Information is one record for the whole file rather than a collection of elements, which is the likeliest reason pairing it with an element category such as Sheets is the combination that bites. If you genuinely need both a project-wide value and a per-sheet value, that is two parameters with two names, not one parameter with two categories.

Get the category right and the field comes alive immediately. Type the consultant’s name into Project Information and it appears across every sheet in the set at once.

Multi-line text, and why an address needs it

The address parameter goes in the same way, and this is where the earlier type decision pays off. Because it was created as multi-line text, Project Information gives you a small expandable box rather than a single line, so a street, a city and a postcode sit on three lines the way they do on a letterhead. A single-line text parameter forces the whole address into one run of characters, and the only fix at that point is a new parameter and a re-edited label.

Put it in the template, not just in this project

The video closes on the point that matters most to a firm rather than a single job: save the project as a template so the parameters do not have to be rebuilt next time. Project parameters live in the project file. Start a fresh model from the out-of-the-box template and every one of them is gone, even though the title block family still carries its labels. You get the same dead fields, and somebody repeats the whole exercise.

The office template is where this belongs: title block families loaded, shared parameter file location agreed, project parameters already mapped to the right categories, consultant fields blank and ready to fill. Our guide to the Revit project template and office BIM standards covers what else should be baked in at the same time. If you are building the title block itself rather than editing an existing one, family creation fundamentals covers the geometry and parameter side of it.

Sheet data is a schedule problem too

One last thing the sheet case makes obvious. Once consultant fields, drawn-by fields and package names are shared parameters, they are schedulable, which means a sheet list becomes a checking tool rather than a contents page. Build a sheet list with Sheet Number, Sheet Name, Current Revision and your per-sheet fields as columns, and every blank cell is a sheet that will go out incomplete. That is the same QA thinking applied later in this guide, aimed at the drawing set instead of the model. If your sheets are generated in bulk rather than by hand, the same parameters carry through a sheet creation workflow driven from Excel and Dynamo.

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. Worth knowing before you build this one: rooms, areas and MEP spaces are three different Revit objects that schedule from three different places, and mixing them is what produces two conflicting area figures on the same project. Our guide to rooms, areas and MEP spaces sets out which to use where.
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 your BIM naming conventions and 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. Once the same checks need to run across a dozen files, they are worth scripting: a short pyRevit script can collect every door with a blank Mark or dump wall data to CSV in a few lines, and our Python for architects guide has working examples of both.

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.
• Stopping after the family. Adding a shared parameter to a family and reloading it is only half the job. Until the same parameter is added as a project parameter, the field shows on screen and cannot be filled in. This is the single most common “my title block is broken” report, and it is not a broken family.
• Assigning sheet data to more than one category. Pick one. Project Information for a value that is identical on every sheet, the Sheets category for a value that changes per sheet. Two categories on one parameter is not a shortcut, it is a field that fails quietly.
• Single-line text for an address. It cannot wrap onto the three or four lines a consultant block needs, and the type cannot be changed afterwards. Create address fields as multi-line text from the start.

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.
8. Put your title block families, shared parameter file path and project parameters into the office template, so sheet data is wired once instead of rebuilt on every new job.

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 Complete Revit Course walks 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.