This is one of those topics where I've seen entire offices build years of inconsistent data simply because nobody explained the distinction clearly on day one. Get this wrong early and your schedules, tags, and exports quietly become unreliable — and the fix later involves touching every family and instance in the project. Here's the distinction that actually matters in practice.
The three types, side by side
| Type | Scope | Appears in schedules/tags? | Shared across projects? |
|---|---|---|---|
| Project Parameter | Single project only | Yes | No — must be recreated per project |
| Shared Parameter | Defined in an external .txt file, usable across projects and families | Yes | Yes — this is the whole point |
| Global Parameter | Single project; drives geometry/values, not tied to elements directly | No | No |
Project parameters: fine for quick, project-specific needs
If you need a one-off data field — say, a "Contractor Notes" field on doors for a single renovation project — a project parameter does the job. The catch: it lives only in that project file. If you need the same field in your next project, you're recreating it from scratch, and there's no guarantee you'll spell it identically, which quietly breaks any standardized export or template logic down the line.
Shared parameters: the only correct choice for anything tagged or scheduled across projects
A shared parameter is defined once in an external text file and then referenced into any family or project that needs it — critically, it carries a consistent GUID behind the scenes, which is what allows it to actually populate correctly in tags, schedules, and IFC/COBie exports across different files. If your office is delivering BIM data that needs to be consistent project to project — which is effectively mandatory under any ISO 19650-aligned workflow — shared parameters are non-negotiable, not optional polish.
Practical habit: maintain one master shared parameter text file at the office level, version-controlled, and have every project reference that same file. I've inherited too many projects where five different "Fire Rating" parameters existed across different families, none compatible with each other in a schedule, because nobody centralized this from the start.
Global parameters: for relationships inside a project, not data fields
Global parameters don't appear in schedules or tags at all — they exist to drive dimensional or numeric relationships across a project, like keeping a corridor width consistent everywhere it's referenced, or linking a stair riser height to a global floor-to-floor dimension. Think of them as project-wide formula variables, not data you're trying to extract or report on.
A simple decision rule
- Need the data to show up in a schedule, tag, or export, consistently across multiple projects? Shared parameter.
- Need a quick, project-specific data field with no reuse intention? Project parameter — but know the cost later.
- Need to control a dimensional relationship across the model, not extract data? Global parameter.
Setting up a shared parameter file correctly — once, at the start — is exactly the kind of standards discipline we build into our Apex plan, alongside ISO 19650 process training. Details on the Programs page.
Related reading: LOD vs LOIN: Why India's BIM Guidelines Are Quietly Shifting Terminology
