Shared parameter governance for multi-discipline teams

The Three Fire Rating Columns

The handover package had been on the client's server for forty-eight hours before their FM consultant opened it and sent back a single, very quiet email: "Which 'Fire Rating' should we use?"

The project had been a standard commercial fit-out — three disciplines, two hundred families, eighteen months. Nothing exotic. But somewhere between the structural engineer loading the base model in week three, the mechanical contractor adding their equipment schedules in week nine, and the facade specialist importing their curtain-wall families in week fourteen, the shared parameter file had fractured. Three separate Fire Rating parameters now lived inside the model, each with a distinct GUID, each populated by a different discipline, each mapping to a different subset of elements. A multi-category schedule showed them as three separate columns: Fire Rating, Fire Rating, and Fire Rating.

The columns looked identical in the Revit Properties palette. They looked identical in a schedule header. There was no visual signal that they referred to three different internal identities. The FM consultant could not programmatically merge them because the underlying GUID — the identity that software, COBie exporters, and IFC parsers use to distinguish parameters — was different for each one. Merging the display names achieves nothing when the data structures disagree.

This is not an edge case. It is the default outcome on any multi-discipline project where shared parameter governance has not been deliberately designed. The only thing that differs between projects is how long it takes to discover the problem, and whether that discovery happens during design (cheap to fix), at practical completion (expensive), or at handover (catastrophic).

The root cause is conceptually simple: Revit identifies parameters by their GUID, not by the human-readable name displayed in the interface. Two parameters named Fire Rating with different GUIDs are, from Revit's perspective, entirely unrelated. They will not merge into a single schedule column. They will not map to the same IFC property. They will not resolve into a single COBie field. The name is cosmetic. The GUID is identity.

This article explains exactly how that identity system works, where it breaks down on multi-discipline projects, and what a governance pattern looks like that prevents the break from happening. For projects that are already divergent, there is a recovery section. For teams that want to prevent it from the start, there is a canonical registry pattern, a naming convention, a parameter request workflow, and audit tooling.

The audience is BIM Managers, discipline leads, and information managers who bear direct responsibility when the handover package comes back with a quiet, devastating question.

How Revit Shared Parameters Actually Work

The GUID as Identity

Every shared parameter in Revit is assigned a GUID (Globally Unique Identifier) at the moment of its creation. That GUID is a 32-character hexadecimal string formatted in the standard 8-4-4-4-12 pattern — for example, f440bb0c-7518-406c-9b84-1de93ecb2d67. Once assigned, the GUID does not change. Renaming the parameter in the shared parameter file, reloading it into families, or modifying its description does not alter the GUID. Autodesk's own documentation states this plainly: "When a shared parameter is created it is assigned a Guid which will not change."

This immutability is a feature, not a limitation. It is what makes the shared parameter system reliable when it is used correctly. Because the GUID is stable, Revit can unambiguously identify a parameter across:

• Tag families and element families. A door tag that references Fire Rating can pull the value from a door family's Fire Rating parameter because they share the same GUID. Without GUID matching, this connection would fail silently.
• Cross-model references. In a federated BIM environment with linked files, parameters with the same GUID will be recognised as the same parameter across the host and link boundary, enabling consistent scheduling.
• IFC and COBie export pipelines. The IFC exporter maps Revit parameters to IFC property sets using name or GUID lookup. COBie exporters query specific parameter GUIDs when they need, for example, the space number or asset type.
• API-driven workflows. The Revit API exposes Parameter.GUID on the ExternalDefinition interface, allowing addins and Dynamo scripts to locate parameters reliably regardless of what name a user may have assigned in the UI.

The corollary is equally important: two parameters that share a name but differ in GUID are, from Revit's perspective, completely unrelated. Revit will not merge them. No schedule, tag, filter, or API call will treat them as equivalent. The human-readable label is a display convenience; it carries no computational identity.

The Shared Parameter File Format

Shared parameters are stored in external .txt files, entirely separate from any .rvt project file or .rfa family file. This external storage is what makes sharing possible: multiple project files and family files can all point at the same definition source.

The file format is tab-delimited plain text with two block types: GROUP and PARAM. The second line of every well-formed shared parameter file contains the warning # Do not edit manually — which, as we will discuss, is a strong recommendation rather than an absolute prohibition, provided you understand the format precisely.

# This is a Revit shared parameter file.
# Do not edit manually.
*META	VERSION	MINVERSION
META	2	1
*GROUP	ID	NAME
GROUP	1	Architecture
GROUP	2	MEP Services
GROUP	3	Structural
GROUP	4	IFC Parameters
GROUP	5	COBie
*PARAM	GUID	NAME	DATATYPE	DATACATEGORY	GROUP	VISIBLE	DESCRIPTION	USERMODIFIABLE	HIDEWHENNOVALUE
PARAM	a1b2c3d4-e5f6-7890-abcd-ef1234567890	A_FireRating	TEXT		1	1	Fire resistance rating per element (e.g. FRL 90/90/90)	1	0
PARAM	b2c3d4e5-f6a7-8901-bcde-f12345678901	A_SpecSection	TEXT		1	1	CSI/NBS specification section reference	1	0
PARAM	c3d4e5f6-a7b8-9012-cdef-123456789012	M_AirflowSupply	NUMBER		2	1	Supply airflow in L/s per element instance	1	0
PARAM	d4e5f6a7-b8c9-0123-defa-234567890123	M_AirflowExhaust	NUMBER		2	1	Exhaust airflow in L/s per element instance	1	0
PARAM	e5f6a7b8-c9d0-1234-efab-345678901234	S_DesignLoad	NUMBER		3	1	Structural design load in kN/m2	1	0
PARAM	f6a7b8c9-d0e1-2345-fabc-456789012345	COBie.Type.Manufacturer	TEXT		5	1	Manufacturer name for COBie Type sheet	1	0
PARAM	a7b8c9d0-e1f2-3456-abcd-567890123456	COBie.Type.ModelNumber	TEXT		5	1	Model number for COBie Type sheet	1	0

The columns in the PARAM block deserve individual attention:

The GROUP block is purely organisational. Groups appear as collapsible headers in Revit's Shared Parameters editor and can be mapped to any logical taxonomy the organisation uses — typically by discipline, by handover deliverable (COBie, IFC, FM), or by a combination. A parameter's group assignment does not affect its behaviour; it is a navigational aid for the people maintaining the file.

Project Parameters vs. Shared Parameters

The distinction matters more than most documentation emphasises.

Project parameters are defined directly inside a .rvt file. They are created through Manage > Project Parameters > Add, using a type and name provided in the dialog. They can appear in schedules. They cannot appear in tags. Critically, they carry no persistent external identity — no GUID is stored in an external file. If you want the same parameter in another project, you must recreate it manually. There is no mechanism to guarantee that the two recreated parameters are the same entity.

Shared parameters are defined in an external .txt file and loaded into a project or family. They carry a stable GUID. They can appear in both schedules and tags. They can be exported through IFC property set mapping and COBie field mapping. They are the correct mechanism for any parameter that needs to cross file boundaries — between families and host projects, between linked models, or between Revit and downstream software.

Instance vs. Type Parameter Binding

When a shared parameter is loaded into a project or family, you choose whether it binds to instances or types. This choice is consequential and cannot be changed without deleting and recreating the binding.

Type parameters hold a single value shared by all instances of that type. If you change A_FireRating on a Generic Wall - 200mm Concrete type, every wall of that type in the project changes simultaneously. Type parameters are appropriate for information that is intrinsic to the product — a fire rating certified by a manufacturer, a specification section reference, a material classification. They reduce data entry burden and ensure consistency.

Instance parameters hold a value per element. Two doors of the same type can have different instance parameter values. Instance parameters are appropriate for location-specific or installation-specific information — a tag number assigned by the contractor, a barcode scanned at commissioning, an asset ID from the FM system.

The governance implication: a parameter's instance/type binding must be decided at the governance level, documented in the parameter registry, and respected when families and projects are built. A fire rating is almost always a type parameter. An asset ID is almost always an instance parameter. Mixing these up produces data that looks correct in the Properties palette but fails in downstream FM systems that expect consistent binding semantics.

The Binding Lifecycle

Binding connects a parameter definition (from the shared parameter file) to one or more element categories in a project. The binding is recorded in the project's BindingMap, which is the object returned by document.ParameterBindings in the Revit API.

A shared parameter exists independently of its bindings. The same GUID can be bound to doors in one project and to walls in another. The definition — GUID, name, datatype — is fixed in the shared parameter file. The binding — which categories it attaches to, whether it is instance or type — is per-project configuration.

The practical implication for governance: loading a shared parameter file into a project does not automatically bind any parameters. You must explicitly bind each parameter to the relevant categories. Template-first deployment (embedding bindings in the .rte project template) eliminates this manual step for every subsequent project.

There is an important asymmetry between families and projects. When a shared parameter is added to a family (through the Family Editor's Manage > Project Parameters workflow), the family stores the parameter definition directly — including the GUID — in the family file. When that family is loaded into a project, Revit compares the family's parameter GUIDs against the project's existing bound parameters. If the GUID already exists in the project, the family's parameter merges with the project's parameter transparently — same field, same schedule column, same tag binding. If the GUID is new, Revit creates a new SharedParameterElement in the project database. If the GUID exists but the name or datatype conflicts with the project's record of that GUID, Revit throws an error.

This means the family is the primary carrier of shared parameter GUIDs into a project. A well-governed family library, where every family's shared parameters originate from the canonical SP file, is the mechanism through which parameter consistency propagates across projects. Template governance (what is bound in the .rte) and family library governance (what GUIDs are in the .rfa files) must both be maintained for the pattern to work end to end.

One File at a Time

Revit permits only one shared parameter file to be active at a time in the application settings (Application > Shared Parameters). This is not a constraint on the number of parameters a project can use — it is a constraint on the source from which new parameters can be interactively created or browsed. You can change the active shared parameter file at any time without affecting parameters already bound in the project.

The implication for multi-discipline workflows: if the canonical SP file is the single approved source, then every team member's Revit application should point at that file (or a read-only copy of it in their local environment). The active file path is set under Application > Shared Parameters, and it can be enforced through the firm's Revit.ini deployment if the IT infrastructure supports it.

Here is the canonical C# pattern for querying and adding bindings programmatically:

using Autodesk.Revit.DB;
using Autodesk.Revit.ApplicationServices;
using System;
using System.Collections.Generic;
 
/// <summary>
/// Loads a shared parameter from the active shared parameter file
/// and binds it to the specified categories as either instance or type.
/// </summary>
public static void BindSharedParameter(
    Document doc,
    string groupName,
    string parameterName,
    BuiltInCategory[] targetCategories,
    BuiltInParameterGroup uiGroup,
    bool isInstance)
{
    Application app = doc.Application;
    DefinitionFile spFile = app.OpenSharedParameterFile();
 
    if (spFile == null)
        throw new InvalidOperationException(
            "No shared parameter file is set. " +
            "Set the file path via Application.SharedParametersFilename first.");
 
    // Locate the definition in the file
    DefinitionGroup group = spFile.Groups.get_Item(groupName)
        ?? throw new ArgumentException($"Group '{groupName}' not found in shared parameter file.");
 
    ExternalDefinition definition = group.Definitions.get_Item(parameterName) as ExternalDefinition
        ?? throw new ArgumentException($"Parameter '{parameterName}' not found in group '{groupName}'.");
 
    // Build the category set
    CategorySet categories = app.Create.NewCategorySet();
    foreach (BuiltInCategory bic in targetCategories)
    {
        Category cat = doc.Settings.Categories.get_Item(bic);
        if (cat != null && cat.AllowsBoundParameters)
            categories.Insert(cat);
    }
 
    // Check if the parameter is already bound to avoid duplicates
    BindingMap existingBindings = doc.ParameterBindings;
    DefinitionBindingMapIterator iterator = existingBindings.ForwardIterator();
    while (iterator.MoveNext())
    {
        Definition existingDef = iterator.Key;
        if (existingDef is ExternalDefinition extDef && extDef.GUID == definition.GUID)
        {
            // Parameter already bound — optionally add categories to existing binding
            ElementBinding existingBinding = iterator.Current as ElementBinding;
            foreach (Category cat in categories)
            {
                existingBinding?.Categories.Insert(cat);
            }
            existingBindings.ReInsert(existingDef, existingBinding, uiGroup);
            return;
        }
    }
 
    // Create the binding
    Binding binding = isInstance
        ? (Binding)app.Create.NewInstanceBinding(categories)
        : (Binding)app.Create.NewTypeBinding(categories);
 
    using (Transaction tx = new Transaction(doc, $"Bind shared parameter: {parameterName}"))
    {
        tx.Start();
        bool success = doc.ParameterBindings.Insert(definition, binding, uiGroup);
        if (!success)
            throw new InvalidOperationException(
                $"Failed to bind '{parameterName}'. Check datatype compatibility and category allowances.");
        tx.Commit();
    }
}

The SharedParameterElement class represents the parameter definition as it exists in the project. Once a shared parameter is bound, Revit creates a SharedParameterElement in the project database. This element can be queried, and its GuidValue property exposes the GUID for verification against the canonical registry.

// Enumerate all shared parameters currently bound in a project
FilteredElementCollector collector =
    new FilteredElementCollector(doc).OfClass(typeof(SharedParameterElement));
 
foreach (SharedParameterElement spe in collector)
{
    ExternalDefinition def = spe.GetDefinition() as ExternalDefinition;
    if (def != null)
    {
        Console.WriteLine($"Name: {def.Name}, GUID: {def.GUID}, " +
                          $"DataType: {def.ParameterType}");
    }
}

This enumeration is the starting point for the audit workflow described later.

Where Divergence Happens

Understanding the failure modes is prerequisite to designing the governance. There are four primary vectors through which shared parameter divergence enters a project.

Per-Discipline Creation

The most common failure mode is the simplest: each discipline creates their own shared parameter file at the start of a project, adds the parameters they need, and links that file to their model. No one on the team has been told to coordinate. Everyone acts rationally, given what they know, and the result is structurally broken.

The structural engineer creates Fire Rating as a TEXT parameter in group 1 of S_SharedParams.txt, GUID aaa.... The architect creates Fire Rating as a TEXT parameter in group 1 of A_SharedParams.txt, GUID bbb.... The mechanical engineer, who uses a Revit template from their office standard, inherits Fire Rating from that template with GUID ccc.... All three look identical to a human being. All three are different entities to Revit.

When the models are federated into a single project for coordination review, the schedule shows three columns. When the COBie exporter runs, it finds three competing candidates for the Pset_WallCommon.FireRating mapping. When the handover package is assembled, someone has to manually decide which column represents ground truth — and typically they cannot tell, because all three are partially populated.

The governance fix is structural: there must be exactly one shared parameter file that issues GUIDs for the project, and all disciplines must use it. This is not a policy preference; it follows directly from how Revit identity works.

Addin-Injected Parameters

A growing class of Revit addins — clash detection integrations, FM connectors, specification tools, model-checking platforms — inject shared parameters into projects programmatically. These addins typically carry their own shared parameter file, bundled at installation, and they bind parameters to project categories without asking permission.

The result is that a project accumulates parameters from multiple sources: the project's own shared parameter file, the COBie extension's file (located by default at C:\Program Files (x86)\Autodesk\COBie Extension\COBie Extension Shared Parameters.txt), the clash detection integration's file, and so on. Each of these may define parameters with names that overlap with the project's own parameters, but with different GUIDs.

Detecting addin-injected parameters requires enumerating SharedParameterElement objects in the project database, as shown in the API snippet above, and comparing their GUIDs against the canonical registry. Any GUID that does not appear in the registry is either an addin injection, a consultant import, or a manually created outlier. All three require investigation before they can be classified.

Manufacturer-Supplied Families

Manufacturer content is a persistent governance hazard. A pump family downloaded from a manufacturer's BIM portal may contain a Fire Rating, Manufacturer, Model Number, and Warranty Period shared parameter — all defined in the manufacturer's own shared parameter file, with GUIDs that no project governance process has ever touched.

When that family is loaded into a project, Revit loads its shared parameter definitions alongside it. If the project already has a Fire Rating parameter with a different GUID, Revit will display two Fire Rating columns in a multi-category schedule — or, worse, the family's parameter will silently fail to merge with the project's parameter when a user attempts to create a combined schedule.

Autodesk's official documentation on this conflict describes the error: "The shared parameter cannot be added with name [X] and type [Y] because it conflicts with the existing name [Z] and type [W]." This error fires when a family carries a shared parameter whose GUID already exists in the project but under a different name, or whose name matches an existing parameter but with a different GUID. Both are GUID mismatches; Revit surfaces them differently depending on which side of the mismatch is visible.

The resolution is to open the manufacturer family, replace its shared parameters with the project's canonical parameters (same GUID), and reload it. This is not a small task when the project has accumulated dozens of manufacturer families. The governance fix is to audit all manufacturer families before they enter the project library, as part of a family review and approval process.

Project Archive Parameters

A subtler problem occurs when a project template has accumulated parameters from previous projects — parameters that were once needed, were never removed, and whose original purpose is now undocumented. These "archive parameters" inflate every schedule, pollute the Properties palette, and occasionally shadow the parameters being created for the current project.

Revit does not provide a visible purge mechanism for shared parameters in the standard UI. A parameter that is bound to categories and has no values on any element will not appear in the Purge Unused dialog. The only reliable method for finding and removing orphaned parameters is through the SharedParameterElement API enumeration, followed by targeted deletion using document.Delete(element.Id).

The governance fix is a periodic audit — at least once per project phase, and before any major file handover — that reconciles the project's bound parameters against the canonical registry and removes anything not in the approved list.

The Renaming Trap

A word on a specific failure mode that catches experienced practitioners: renaming a shared parameter in the .txt file does not rename it in projects and families where it is already bound. The GUID was loaded when the parameter was first bound, and it persists in the project database independently of the file. Revit reads the file to find new parameters; it does not continuously re-read it to update bound parameters.

This means that a "governance fix" that consists of renaming parameters in the shared parameter file, without reloading and rebinding in every affected project and family, produces a mismatch: the file says A_FireRating, the project still says Fire Rating (the old name). The GUID is the same, so Revit does not complain. The data is intact. But the name shown in the Properties palette is now misleading, and any schedule or tag that displays the parameter name as a column header will show the old name until each project is individually updated.

The correct renaming procedure — if renaming is unavoidable — is to define the parameter with the new name in a clean project before loading any families, so that the project's internal record of the parameter's name is initialised with the new label. Families loaded after that point adopt the new name. Families loaded before that point retain the old name until reloaded. This is time-consuming and error-prone at scale. The practical recommendation is to get names right before first use, and treat renaming as a last resort.

The Governance Pattern

The following pattern is designed to be implementable by a team with a BIM Manager, a shared network or cloud location, and a version control system. It does not require enterprise infrastructure, paid tooling, or large budgets. Every component described here can be implemented with Revit, Git, a text editor, and Dynamo.

Principle 1: One Canonical File, One Source of GUIDs

The governance pattern begins with a single commitment: there is exactly one shared parameter file that is the source of truth for the project (or, for a firm, for all projects). This file is the only place where new shared parameter GUIDs are generated. Every discipline, every family author, every addin configuration references this file. No other file issues GUIDs for elements that will be coordinated across disciplines.

This file is called the canonical SP file. It lives in a version-controlled repository, and changes to it go through a formal request workflow.

Canonical File Under Version Control

project-bim-standards/
├── shared-parameters/
│   ├── ACME_SharedParams_v1.3.txt   ← canonical SP file (current release)
│   ├── CHANGELOG.md                 ← human-readable log of every change
│   └── archive/
│       ├── ACME_SharedParams_v1.0.txt
│       ├── ACME_SharedParams_v1.1.txt
│       └── ACME_SharedParams_v1.2.txt
├── ifc-mapping/
│   └── ACME_IFCPropertySets.txt    ← IFC parameter mapping file (versioned alongside SP)
├── cobie-mapping/
│   └── ACME_COBieParameterMap.csv  ← COBie field mapping (SP GUID → COBie column)
└── templates/
    ├── ACME_Project_Template.rte   ← pre-binds all canonical parameters
    └── ACME_Family_Template.rft

The Git workflow for releasing a new version of the shared parameter file:

# Checkout a new branch for the parameter addition
git checkout -b feat/add-acoustic-rating
 
# Edit the canonical SP file (add new PARAM entries with generated GUIDs)
# Never change existing GUIDs — only add new entries
 
# Stage only the SP file and changelog
git add shared-parameters/ACME_SharedParams_v1.3.txt
git add shared-parameters/CHANGELOG.md
 
# Commit with a structured message referencing the request ticket
git commit -m "feat(params): add A_AcousticRating_dB TEXT for Walls, Floors, Ceilings
 
Requested by: Architecture lead (Issue #47)
GUID: d9e0f1a2-b3c4-5678-90de-f01234567890
Binds to: Walls (Type), Floors (Type), Ceilings (Type)
COBie mapping: none
IFC mapping: Pset_WallCommon.AcousticRating
Reviewed by: BIM Manager"
 
# Merge to main after review
git checkout main
git merge feat/add-acoustic-rating
 
# Tag the release
git tag -a v1.3 -m "Release v1.3 — Acoustic parameters added"
git push origin main --tags
 
# Publish the new file to the controlled network/ACC location
# (automated via CI or manual copy from the tagged commit)

Naming Convention

Parameter names should be self-documenting: a practitioner reading the name should immediately understand which discipline owns it, what it represents, and what its binding scope is. The following convention is used across this pattern:

Format: {DisciplinePrefix}_{SemanticName}_{BindingScope}

Length constraint: Parameter names are truncated in some schedule column headers. Keep names under 40 characters. If a unit is needed for disambiguation, append it as a suffix: M_AirflowSupply_Ls, S_DesignLoad_kNm2.

No spaces in names. Spaces in shared parameter names cause failures in IFC property set mapping and create inconsistencies in some COBie exporters. Use PascalCase throughout.

Avoid abbreviations beyond discipline prefixes. A_FireResistanceLevel is preferable to A_FRL if the audience includes FM operators who may not know Revit conventions.

Reserved prefixes for cross-discipline parameters:

Parameter Request Workflow

New parameter requests should go through a lightweight but formal process. The goal is not bureaucracy — it is preventing duplicate creation, which is cheap at request time and extremely expensive to fix post-handover.

Request Submission

The discipline lead submits a request containing: proposed name (per naming convention), datatype, binding (instance or type), target categories, business justification, and whether a COBie or IFC mapping is required. A simple form or issue tracker ticket is sufficient. Email threads are not — they lose the audit trail.

BIM Manager Search

Before creating any new GUID, the BIM Manager searches the canonical file for semantically equivalent parameters. Common duplications to check: FireRating / Fire Rating / FRL / Fire Resistance Level; AssetId / Asset Number / TagNumber / BarCode; Manufacturer / ManufacturerName / MfrName. If an equivalent exists, the requester is pointed to the existing GUID and shown how to bind it to their target categories.

Review and Approval

If no equivalent exists, the BIM Manager reviews: Is the datatype correct? (Never TEXT for a numeric value — it breaks IFC numeric property sets and COBie quantity fields.) Is the binding scope (instance/type) appropriate? Are the target categories correct? Does the name meet the convention?

GUID Generation

New entries are added to the canonical file. Revit generates the GUID when the file is edited through the Revit Shared Parameters editor (Manage > Shared Parameters). If adding entries manually to the .txt file, generate a properly random UUID (RFC 4122) using a trusted generator — do not invent GUIDs by hand, and never reuse or increment a previous GUID. A GUID with a pattern like 00000000-0000-0000-0000-000000000001 is a reliable signal of manual construction and a source of collision risk.

Versioning and Publishing

The new entry is committed to Git, tagged with the next semantic version, and published to the controlled network/ACC location. All team members are notified through the project communication channel (not email). The CHANGELOG is updated with the GUID, the requestor, the date, and the business justification.

Template Update

If the parameter should be present in all new projects, the project template (.rte) is updated to include the binding. Family templates (.rft) are updated if the parameter should be present in all new families of a given category.

Weekly Intake

On large projects with active parallel discipline work, the request workflow can become a bottleneck if every new parameter requires a synchronous review. A practical mitigation is a weekly intake window: requests submitted by end of day Wednesday are reviewed, approved or queried, and published in a batch on Friday morning. This creates a predictable cadence, reduces the overhead of individual reviews, and gives the BIM Manager time to batch-search for duplicates across the full set of pending requests.

The weekly publication schedule also aligns with project coordination meetings, so parameter changes can be announced and any bindings distributed in the same communication cycle.

For smaller teams or projects where a weekly cadence is too slow, a 48-hour service level agreement (SLA) is a reasonable alternative: any request submitted receives a decision (approved, queried, or rejected with explanation) within two business days. The key principle is that the request goes through a human review — even a brief one — before a new GUID is generated. Asynchronous creation, where anyone can add a parameter without review, is the direct cause of the divergence this pattern is designed to prevent.

Deprecation, Not Deletion (Mostly)

Parameters accumulate over a project's lifetime. The correct response to a parameter that is no longer needed is usually deprecation rather than deletion. Deprecation means the parameter remains in the canonical file and in the project's bound set, but it is documented as deprecated in the CHANGELOG, its description is updated to indicate its deprecated status, and new families are not built with it.

The rationale for preferring deprecation is traceability. If a parameter was populated during an earlier phase and appears in a previous information delivery, deleting it from the project erases the record of that delivery. Asset owners and FM operators often need to audit historical data. A deprecated parameter that still holds its historical values is more useful to them than a clean project with no record of what was once recorded.

Deletion is appropriate when:

• The parameter was created in error and has never held meaningful data.
• The parameter is a duplicate (different GUID, same semantics as a canonical parameter) and its values have been migrated to the canonical parameter.
• The project is at an early phase and the parameter was a prototype that has been superseded.

In all other cases, mark it deprecated and leave it.

Datatype Discipline

The datatype decision is permanent in practice. Once a parameter with a given GUID and datatype has been used in a project or family that has been distributed to the team, changing the datatype requires generating a new GUID (because Revit will reject a parameter file that changes the datatype of an existing GUID). This effectively means a new parameter entity, a data migration, and a deprecation of the old parameter.

The two datatype mistakes that cause the most downstream pain are:

1. Using TEXT for numeric values. A parameter like M_AirflowSupply that holds a number should be NUMBER, not TEXT. Using TEXT prevents IFC numeric property set mapping from working correctly — the IFC schema requires typed numeric properties, not strings. It also prevents formula-based calculations in Revit schedules. Teams often use TEXT for numeric parameters because it avoids the unit suffix that Revit appends to NUMBER parameters in some contexts; the correct fix is to name the parameter with its unit (e.g., M_AirflowSupply_Ls) rather than stripping the type information.

2. Using NUMBER for classification codes. Codes like specification section numbers (e.g., 09 91 13) or classification references (e.g., Pr_20_93_08) should be TEXT. If stored as NUMBER, any leading zeros are silently stripped and non-numeric characters cause errors. Classification data is always TEXT.

The governance rule: propose the datatype with the parameter request, get it reviewed before the GUID is generated, and treat the first approved datatype as immutable for the life of the parameter.

COBie Mapping

COBie (Construction Operations Building Information Exchange) is the primary handover data standard for built assets in many jurisdictions. The COBie schema defines worksheets — Contact, Facility, Floor, Space, Zone, Type, Component, System, Assembly, Connection, Spare, Resource, Job, Impact, Document, Attribute, Coordinate — each with a defined set of columns. Revit parameters need to be explicitly mapped to these columns for the COBie export to produce valid output.

The canonical mapping document (ACME_COBieParameterMap.csv) records the relationship between the project's shared parameter GUIDs and the COBie worksheet columns they feed:

GUID,ParameterName,COBieWorksheet,COBieColumn,Notes
f6a7b8c9-d0e1-2345-fabc-456789012345,COBie.Type.Manufacturer,Type,Manufacturer,Required by EIR
a7b8c9d0-e1f2-3456-abcd-567890123456,COBie.Type.ModelNumber,Type,ModelNumber,Required by EIR
b8c9d0e1-f2a3-4567-bcde-678901234567,COBie.Type.WarrantyGuarantorParts,Type,WarrantyGuarantorParts,Optional
c9d0e1f2-a3b4-5678-cdef-789012345678,COBie.Component.SerialNumber,Component,SerialNumber,Instance param
d0e1f2a3-b4c5-6789-defa-890123456789,FM_SpaceNumber,Space,Name,Maps to Revit Room Number
e1f2a3b4-c5d6-7890-efab-901234567890,FM_SpaceCategory,Space,Category,Occupancy classification

This mapping document is maintained alongside the canonical SP file under the same Git workflow. When a new COBie-required parameter is added to the SP file, its mapping entry is added to this CSV in the same commit. The COBie Extension's Parameter Mapping function is then configured to use the project's parameters rather than its defaults.

IFC Mapping

IFC (Industry Foundation Classes) exchange requires a different but related mapping. The IFC exporter for Revit supports a parameter mapping file that routes Revit parameters to IFC property set properties. This file uses a tab-delimited format:

# IFC Parameter Mapping File
# Format: PropertySetName <TAB> IFCPropertyName <TAB> RevitParameterName
Pset_WallCommon	FireRating	A_FireRating
Pset_DoorCommon	FireRating	A_FireRating
Pset_WindowCommon	FireRating	A_FireRating
Pset_SpaceCommon	IsExternal	A_IsExternal
Pset_BuildingCommon	NumberOfStoreys	A_NumberOfStoreys

The same Revit parameter (A_FireRating) can be mapped to multiple IFC property sets, enabling consistent fire rating data to flow to the correct IFC entities regardless of element type. This mapping file is versioned alongside the SP file and the COBie mapping in the same repository.

Audit and Reconciliation

The audit workflow has two modes: pre-handover audit (run before any major information delivery) and ongoing audit (run monthly or after any significant family loading event).

Pre-handover audit checklist:

□ Enumerate all SharedParameterElement GUIDs in the project
□ Cross-reference every GUID against the canonical SP file
□ Flag any GUID not present in the canonical file (addin, manufacturer, or rogue creation)
□ For each flagged GUID, determine: is there a canonical equivalent? If yes, migrate data.
  If no, does it need to be added to the canonical file (with a retroactive entry)?
□ Check all COBie-mapped parameters are populated on required element categories
□ Check all IFC-mapped parameters are populated with valid values
□ Run a multi-category schedule with Family, Type, and all canonical parameters visible —
  confirm no unexpected empty columns on elements that should carry data
□ Verify no duplicate column headers in multi-category schedules (signal of GUID divergence)
□ Confirm no QC_ prefixed parameters remain bound (remove before handover)

The Dynamo implementation of the GUID enumeration audit:

# Dynamo Python node: audit shared parameters against canonical file
import clr
clr.AddReference('RevitAPI')
from Autodesk.Revit.DB import FilteredElementCollector, SharedParameterElement
 
doc = UnwrapElement(IN[0])         # Revit Document
canonical_guids = IN[1]            # list of GUID strings from canonical SP file
 
collector = FilteredElementCollector(doc).OfClass(SharedParameterElement)
 
results = []
for spe in collector:
    defn = spe.GetDefinition()
    guid_str = str(defn.GUID) if hasattr(defn, 'GUID') else 'N/A'
    status = 'CANONICAL' if guid_str in canonical_guids else 'UNREGISTERED'
    results.append({
        'Name': defn.Name,
        'GUID': guid_str,
        'Status': status,
        'ElementId': spe.Id.IntegerValue
    })
 
OUT = results

Recovery strategy for already-divergent projects:

If the project already has multiple Fire Rating parameters with different GUIDs, the recovery sequence is:

Identify Ground Truth

Determine which GUID should be canonical. This is usually the one with the most data (most elements populated), or the one that matches the canonical file if one exists. Record this as the "keeper GUID".

Export Existing Values

For each non-canonical parameter, create a schedule that exports the element ID and current parameter value to a spreadsheet. This is the recovery dataset.

Rebind Families

For each family that carries a non-canonical parameter, open the family, delete the non-canonical shared parameter, add the canonical version (same GUID), reload. This eliminates the non-canonical definition from the project's family library.

Reimport Values

Use a Dynamo or API script to write the exported values back to the canonical parameter, matching by element ID. Verify that values have migrated correctly before proceeding.

Delete Non-Canonical SharedParameterElements

Using the API deletion approach (delete by element ID), remove the orphaned SharedParameterElement objects from the project database. Verify the deletion did not affect any schedules, tags, or filters that referenced the non-canonical parameter.

Update Schedule and Tag Definitions

Rebuild any schedules and tags that referenced the non-canonical parameter to use the canonical one. Test that values display correctly.

Document in CHANGELOG

Record the recovery action in the project's BIM management log, including which GUIDs were superseded, when, and by whom.

This recovery process is labour-intensive. On a project with two hundred families and three divergent Fire Rating GUIDs, the family-by-family rebinding step alone can take several days. This is the cost of late discovery. Early governance is, by comparison, essentially free.

Anti-Patterns

Copy-Paste Merging

The most common "fix" attempted by practitioners who have discovered parameter divergence is to open both shared parameter files in a text editor, copy the PARAM entries from one into the other, and save. The intent is to consolidate parameters.

The result depends on whether the GUIDs happen to match. If you are copying a parameter from File B into File A because File A is missing it, and the GUID in File B is one the project has never seen, the copy is safe — you have added a new definition. But if File A already contains a parameter with the same name and a different GUID, copying creates a file with two PARAM entries for the same name (which Revit will reject) or, worse, a file where the copied entry's GUID silently shadows an existing definition in a project that was previously pointed at File A.

Manual editing of the shared parameter file is not prohibited, but it requires understanding exactly what each column does, especially the GUID column. The warning "Do not edit manually" in line 2 of every shared parameter file is not there to prevent technical edits — it is there to prevent uninformed edits. If you understand the format, manual editing with a Tab-separated editor (not Word, not Google Docs — both corrupt invisible whitespace) is safe and sometimes the fastest way to perform bulk maintenance.

The anti-pattern to avoid: copy-pasting PARAM blocks between files without first verifying that the destination file does not already contain an entry for the same GUID.

GUID Rewriting

Occasionally, a practitioner discovers that a parameter's GUID was generated incorrectly — for example, by an addin that used a non-random GUID, or a manual entry that reused a previous value. The temptation is to edit the GUID in the shared parameter file to "fix" it.

This is destructive. Any project or family that was pointed at this file and loaded this parameter will have recorded the original GUID in its database. Changing the GUID in the file creates a mismatch: the file now says new-guid, but every project says old-guid. Revit will no longer recognise the file's entry as corresponding to the project's bound parameter. Families reloaded after the change will appear to have a "new" parameter with no values, while the original parameter's data remains under the now-unresolvable old-guid.

The correct response to a malformed GUID is not to rewrite it. The correct response is to add a new parameter with a correctly generated GUID, migrate data via the recovery sequence, and deprecate the old parameter.

API Deletion Without Backup

The API deletion of SharedParameterElement objects is powerful and irreversible within the scope of a transaction commit. Practitioners who discover the SharedParameterElement enumeration pattern sometimes use it to bulk-delete parameters that appear unused, without fully verifying that no data exists on any element.

A parameter can have zero values visible in a schedule and still hold data on elements that are not included in the schedule's category filter. Bulk deletion based on schedule visibility alone is an unreliable heuristic. Use the API to enumerate all elements with the parameter bound and check for non-null, non-empty values before treating a parameter as safe to delete.

Ignoring IFC Round-Trip

When a model is exported to IFC and then imported back into Revit — or when a consultant delivers an IFC file that is linked into the host model — shared parameters may be recreated from the IFC property sets with new GUIDs. The IFC importer does not look up the canonical GUID from the project's shared parameter file; it creates new SharedParameterElement objects based on the property set names and types it encounters in the IFC stream.

The result is that after an IFC round-trip, the project may contain duplicates of every parameter that crossed the IFC boundary — the original with the canonical GUID, and the IFC-imported version with a new GUID and typically the same name. These will show as duplicate columns in schedules.

The governance fix is to audit the project's bound parameters after every IFC import and delete any SharedParameterElement objects whose names duplicate canonical parameters but whose GUIDs do not match the canonical file. This audit should be a defined step in the project's information management workflow for any phase involving IFC file exchange.

Treating the Display Name as the Identity

A persistent source of confusion is treating the parameter's display name as its identity, rather than its GUID. This manifests in several ways:

• Creating a "duplicate check" by searching for parameters with the same name, and concluding no duplicate exists if the name search returns one result. The correct check is by GUID, not by name.
• "Fixing" a discipline's non-canonical parameter by renaming it to match the canonical name. This changes what users see in the interface but changes nothing about the parameter's identity. The GUID is still different. The IFC mapping still fails. The COBie exporter still sees two separate entities.
• Reporting parameter "conflicts" in model review meetings by comparing name lists, rather than GUID lists. A GUID comparison is the only reliable method for detecting true parameter identity conflicts.

The practical recommendation: any parameter audit tool, Dynamo script, or spreadsheet that your team uses to manage parameters should display the GUID alongside the name. Practitioners who can see the GUID quickly develop an intuition for when something looks wrong — a zero- heavy GUID, an incrementing GUID, or a GUID that appears twice in a list are all immediate signals of a governance failure.

Case Studies

Case Study 1: Infrastructure to FM — The Divergent Handover

A 45,000 m² mixed-use development in southeast Asia involved five disciplines across three firms: base building architect, interior architect, MEP engineer, structural engineer, and facade specialist. The project ran for 26 months. BIM coordination was managed through a federated Navisworks model.

No shared parameter governance was in place at project initiation. Each firm used its own shared parameter file, its own naming conventions, and its own grouping structure. Parameter exchange was coordinated informally through email.

At practical completion, the FM consultant commissioned a parameter audit in preparation for the CAFM system import. The audit found:

• 14 distinct Fire Rating parameters across the federated model, with 14 different GUIDs
• 7 distinct Room Number parameters, preventing consistent space scheduling
• 6 distinct Manufacturer parameters mapped to different COBie fields
• 3 distinct Asset ID parameters, none of which matched the CAFM system's expected field

Total rework cost was estimated at 340 consultant hours over six weeks, encompassing family remediation, data migration, schedule rebuilding, and COBie export validation. The project handover was delayed by four weeks.

The corrective action established a canonical parameter file retroactively, migrated data from the 14 Fire Rating variants into a single canonical parameter, and documented the COBie and FM mappings in a parameter registry that became the mandatory starting document for subsequent projects at the firm.

Lesson: The cost of post-hoc governance is one to two orders of magnitude higher than the cost of establishing governance at project inception. The migration work itself — four weeks of six consultants — was roughly equivalent to the total effort that initial governance would have required across the full project lifecycle.

Case Study 2: Firm-Wide Rollout

A mid-sized architectural practice with twelve concurrent Revit projects undertook a governance initiative after discovering that their family library contained 23 variations of a Specification Section parameter, produced over five years of independent project work. Schedules that attempted to report specification cross-references produced inconsistent results depending on which families were present in a given project.

The governance initiative proceeded in four phases over eight weeks:

Phase 1 (Weeks 1–2): Audit. The BIM Manager used a Dynamo script to enumerate all SharedParameterElement objects across all twelve active projects. The audit identified 187 unique GUIDs, of which 34 corresponded to the same semantic concept (specification section) under different names and GUIDs.

Phase 2 (Weeks 3–4): Registry Definition. The canonical parameter list was defined by semantic deduplication: for each cluster of equivalent parameters, one was designated canonical (the one with the most current projects using it), and the rest were marked for deprecation. The naming convention was applied: all canonical parameters were prefixed with the discipline code and suffixed with the binding scope where ambiguous.

Phase 3 (Weeks 5–6): Family Remediation. The family library was processed systematically. Families with non-canonical parameters were updated in batches by category. A Dynamo script automated the parameter swap for simple cases (same datatype, same binding scope); complex cases (type/instance mismatch, datatype change) were handled manually. 340 of the firm's 420 content families required at least one parameter update.

Phase 4 (Weeks 7–8): Project Rollout. The canonical SP file was published to the firm's ACC Docs library under a read-only folder. The project template was updated to pre-bind all canonical parameters. All twelve active projects were updated to point their shared parameter file reference at the canonical file and had their family libraries refreshed.

Outcome: Post-rollout, cross-project schedules that previously required manual curation became reliable. The Specification Section schedule in particular, which had been rebuilt manually every three months, became self-maintaining. The practice adopted a parameter request workflow and assigned the BIM Manager as the sole editor of the canonical file.

Lesson: Even a firm-level retroactive cleanup, while expensive (the initiative consumed approximately 80 BIM Manager hours and 60 technician hours), pays back quickly when schedules and handover packages stop requiring manual reconciliation. The ROI on the governance investment was positive within the first post-rollout project.

Case Study 3: Manufacturer Content Integration

A hospital fit-out project required the integration of approximately 600 manufacturer-supplied Revit families from 40 vendors. The specification required COBie handover for all mechanical and electrical assets. The BIM manager established a family intake process before any manufacturer content was loaded:

1. Each incoming family was opened in an isolated test project.
2. A Dynamo script enumerated its shared parameters and compared them against the canonical file.
3. Any parameter not in the canonical file was flagged for review.
4. If the parameter was semantically equivalent to a canonical parameter, the family was returned to the BIM team for parameter replacement before project loading.
5. If the parameter represented genuinely new data, a parameter request was submitted and the canonical file was updated before the family was loaded.

Of 600 incoming families, 412 required parameter remediation before loading. The most common issue was manufacturer-specific Model Number, Manufacturer, and Warranty Period parameters with vendor-specific GUIDs. The remediation effort averaged 8 minutes per family for simple swaps and 45 minutes for families with nested parameter dependencies.

Total intake remediation effort: approximately 85 hours across the intake period. The COBie export at practical completion required no manual reconciliation of asset parameters — a result the project team attributed directly to the intake governance.

Lesson: Manufacturer content governance is unglamorous but high-leverage. The 85 hours spent on intake remediation prevented what the case study 1 post-mortem estimated at 340 hours of post-handover recovery work on a project of similar scale.

Case Study 4: The Template That Travelled

A structural engineering firm maintained a single Revit project template used across all their projects. The template had been built in 2018 and updated incrementally since then. Over five years, it had accumulated shared parameters from fifteen distinct projects — parameters that had been bound to the template's categories as part of bespoke project setups and never removed when the project was closed.

The template's shared parameter file was an accumulation of additions from six different engineers' personal files, consolidated manually (via copy-paste in Notepad) at various points over the years. The result was a file with 214 PARAM entries, many of which were semantically duplicated: S_SteelGrade, Steel Grade, S_GradeSteel, and SteelGradeType all existed with different GUIDs and partially overlapping category bindings.

The symptom that finally triggered the investigation was a COBie handover for a public infrastructure project, where the client's information manager reported that the exported COBie spreadsheet contained empty columns for parameters that the structural model appeared to populate in Revit. The root cause: the COBie mapping had been configured to use S_SteelGrade, but the families in the project were mostly populated with Steel Grade (a different GUID, inherited from an older template era). The COBie exporter found the correctly mapped parameter but found no values under it, because the data was under a different GUID.

The remediation required:

1. Identifying the four SteelGrade variants and determining which held the most complete data.
2. Migrating data from the three non-canonical variants to the canonical one.
3. Updating the COBie mapping to reference the canonical GUID.
4. Rebuilding the project template to include only canonical parameters.
5. Re-issuing the COBie export.

The total elapsed time from problem identification to corrected handover delivery was eleven days — three of which were the data migration, four were the template rebuild and QA, two were the re-export and validation, and two were the communication overhead with the client.

The firm subsequently adopted a full parameter registry workflow, including Git version control for the canonical SP file and a formal parameter deprecation process. The template was rebuilt from scratch using only canonical parameters.

Lesson: Templates that are never audited become archaeological sites. Each layer of accumulated parameters from past projects represents a governance debt that will eventually be called. A quarterly template audit — enumerate all bound parameters, cross-reference against canonical, remove anything deprecated — prevents this accumulation from reaching a point where the debt is too large to service quickly.

Limits and Caveats

This Pattern Does Not Eliminate All Parameter Problems

The canonical SP file pattern solves the GUID divergence problem. It does not solve:

• Data quality. A correctly identified A_FireRating parameter with a canonical GUID can still contain incorrect, inconsistent, or missing values. Data quality governance requires model checking workflows, completion schedules, and review gates that are separate from parameter governance.
• Mapping completeness. Having a canonical COBie.Type.Manufacturer parameter in the SP file does not guarantee that every family in the model has it populated. COBie completeness requires targeted data audits against the EIR's information requirements.
• Calculation logic. Shared parameters hold data; they do not validate it. A fire rating value of "FRL 999/999/999" will be accepted without complaint. Validation logic belongs in model-checking rules (Revit worksharing monitors, Solibri, Navisworks clash rules, or custom API validators).

Revit Version Behaviour

The shared parameter file format has been stable for many Revit versions, and the GUID identity mechanism is well-documented going back to at least Revit 2015. However, a few version-specific behaviours are worth noting:

• The HIDEWHENNOVALUE column was added in a later Revit version. A shared parameter file that omits this column will load correctly in earlier versions; a file that includes it will load correctly in versions that support it and ignore the column in versions that do not. If your team uses mixed Revit versions, test the SP file in the oldest version in use.
• ForgeTypeId and SpecTypeId changes in Revit 2022+ affect how parameter types are referenced in the API. If you are writing API tooling that reads parameter types, test against the versions your team uses. The GUID identity mechanism itself is unaffected.

Workshared Models

In a Revit workshared model, the SharedParameterElement objects are part of the central file. All operations that modify these elements — binding, unbinding, deleting — require the relevant workset to be editable and the central file to be synchronised. Coordinate parameter changes with all active team members before performing them. A parameter deletion that runs while team members have the project open and local files unsynchronised will cause sync conflicts that are difficult to resolve.

ISO 19650 Alignment

This governance pattern is consistent with the information management principles of ISO 19650, which requires that information be produced to meet defined information requirements, in a structured and auditable way, with traceability to the appointing party's EIR. The canonical SP file, the COBie mapping, and the IFC mapping together constitute the technical implementation layer of those requirements. However, ISO 19650 compliance in the full sense requires a broader information management framework (BEP, MIDP, TIDP, appointment documents) that is outside the scope of this article. The parameter governance pattern described here is a necessary but not sufficient condition for ISO 19650-aligned information delivery.

Cloud-Based Collaboration Environments

If your project uses Autodesk Construction Cloud (ACC) or BIM 360 for workshared models, the shared parameter file path stored in the project must be accessible from all collaborators' machines. A path like C:\CompanyBIMStandards\shared-params.txt will work on your machine and fail silently for a remote collaborator. Use a UNC network path, an ACC-synced local folder, or a path within a Revit Server vault that all collaborators can reach.

The failure mode when the path is inaccessible is not a hard error — Revit will still open the project, but any attempt to interactively add or browse parameters will fail with a message that no shared parameter file is set. Team members who encounter this message often set their own shared parameter file as a workaround, which is exactly the per-discipline creation failure mode described earlier. Verify that the shared parameter file path is consistently accessible as part of project onboarding for each new team member.

This Is Not a One-Time Setup

The governance pattern described in this article is a continuous practice, not a one-time configuration. Projects evolve. New disciplines join. New manufacturers are specified. New FM requirements emerge at each project phase. The canonical file, the COBie mapping, the IFC mapping, and the project template all require active maintenance across the project lifecycle.

The BIM Manager role on a governed project includes, at minimum: processing parameter requests through the weekly intake workflow; performing quarterly template audits; running pre-handover parameter audits at each phase gate; and updating the COBie and IFC mapping when the EIR's information requirements are revised.

Teams that treat parameter governance as a once-at-project-start task discover, usually at the same painful moment described in the lede of this article, that the parameters they defined at project start have diverged significantly from what the project actually contains twelve months later.

Sources and Further Reading

The following sources were consulted in the preparation of this article and are recommended for practitioners who want to go deeper on any of the topics covered.

Autodesk Official Documentation

1. Autodesk, "Shared Parameters," Revit 2025 Help, accessed June 2026. https://help.autodesk.com/view/RVT/2025/ENU/?guid=GUID-E7D12B71-C50D-46D8-886B-8E0C2B285988

2. Autodesk, "Export Shared Parameters to a Shared Parameter File," Revit 2025 Help, accessed June 2026. https://help.autodesk.com/view/RVT/2025/ENU/?guid=GUID-AD648C07-0C2F-478D-AD9D-4F9A5FF515E6

3. Autodesk, "Binding (Revit API Developer's Guide)," Revit 2025 API Help, accessed June 2026. https://help.autodesk.com/view/RVT/2025/ENU/?guid=Revit_API_Revit_API_Developers_Guide_Basic_Interaction_with_Revit_Elements_Parameters_Shared_Parameters_Binding_html

4. Autodesk, "COBie Extension for Revit — Parameter Mapping," Autodesk Support, accessed June 2026. https://www.autodesk.com/support/technical/article/caas/tsarticles/ts/zI80FgYb4CixZWcjOqn4V.html

5. Autodesk / Open Source, "IFC Shared Parameters-RevitIFCBuiltIn.txt," revit-ifc GitHub repository, accessed June 2026. https://github.com/Autodesk/revit-ifc/blob/master/Source/RevitIFCTools/IFC%20Shared%20Parameters-RevitIFCBuiltIn.txt

Community and Practitioner References

6. IMAGINiT Technologies, "Investigating Revit's Shared Parameter File," IMAGINiT Building Solutions Blog, accessed June 2026. https://resources.imaginit.com/building-solutions-blog/investigating-revits-shared-parameter-file

7. Triple Zero Blog (formerly OpenDefinery), "Purging Shared Parameters in Revit," accessed June 2026. https://blog.triplezero.xyz/purging-shared-parameters-in-revit/

8. Triple Zero Blog, "True or False: Shared Parameters Can Be Renamed," accessed June 2026. https://blog.triplezero.xyz/revit-shared-parameters-can-be-renamed

9. Novedge / Design News, "Revit Tip: Revit Shared Parameter Standards and Governance," accessed June 2026. https://novedge.com/blogs/design-news/revit-tip-revit-shared-parameter-standards-and-governance

10. Consense, "How to Standardize Shared Parameters Across Revit Projects," accessed June 2026. https://www.consense.is/en/standardize-shared-parameters-across-revit-projects/

11. mgfx.co.za (Aldred Boyd), "Revit Shared Parameter File Management," accessed June 2026. https://mgfx.co.za/blog/building-architectural-design/revit-shared-parameter-file-management/

Standards

12. International Organization for Standardization, ISO 19650-1:2018 — Organization and digitization of information about buildings and civil engineering works, including building information modelling (BIM) — Part 1: Concepts and principles. Geneva: ISO, 2018. https://www.iso.org/standard/68078.html

13. buildingSMART International, IFC Property Sets documentation, buildingSMART Technical Room, accessed June 2026. https://www.buildingsmart.org/standards/bsi-standards/industry-foundation-classes/