3.2.7 – Parameters

1. Introduction

Parameters are the backbone of Revit’s information system.
They control dimensions, materials, classifications, schedules, tags, formulas, and any data you need to attach to elements or the project environment.

Understanding how the different parameter types work is essential for creating consistent, coordinated BIM models, ensuring accuracy in documentation, and maintaining Arcanary’s One Source of Truth principle.

2. Types of Parameters in Revit

Revit includes several parameter categories, each with a specific purpose.
The main groups are:

  1. Project Parameters
  2. Shared Parameters
  3. Global Parameters
  4. Family Parameters
  5. Type vs Instance Parameters
  6. System Parameters (built-ins)
  7. Reporting Parameters

Each type impacts modeling, schedules, tagging, and interoperability in a different way.

3. Project Parameters

Definition

Project Parameters are defined within a single Revit project file.
They do not appear in tags, and they cannot be transferred into families unless manually recreated.

Used for:

  • Scheduling additional information
  • Classifications (internal only)
  • Notes, comments, categories that don’t require tagging

Key Characteristics

  • Project-specific
  • Cannot be tagged
  • Can be Instance or Type
  • Can be applied to multiple categories

Examples

  • “Acoustic Zone”
  • “Fire Compartment Group”
  • “Internal QC Notes”
  • “Survey Reference ID”

Best practice:
Use for internal, non-tagged information that does not require consistency across multiple files.

4. Shared Parameters

Definition

Shared Parameters are stored in an external .txt file.
They can be used across multiple projects and families and can be tagged.

This is the most powerful parameter type.

Key Characteristics

  • Unique ID stored outside Revit
  • Appears in schedules and tags
  • Works across families, templates, links, and models
  • Requires strict naming and file management

Used For

  • Information that must be tagged
  • Information maintained across multiple files
  • ISO-compliant data structures
  • Classification codes (Arcanary taxonomy)
  • Fire ratings, acoustic ratings
  • Manufacturer data shared across families

Examples

  • “ARCA_Code”
  • “Door Fire Rating – FRL”
  • “Window Acoustic Rating”
  • “Asset ID”
  • “Model Version”

Best practice:
Always use Shared Parameters for any data that must be tagged or reused across projects.

5. Global Parameters

Definition

Global Parameters control dimensions, constraints, and relationships at the project level, similar to formulas in families.

They do not belong to categories and cannot be scheduled.

Key Characteristics

  • Control geometry relationships
  • Drive dimensions across multiple elements
  • Cannot be scheduled
  • Cannot be exported into families

Used For

  • Consistent floor-to-floor heights
  • Standard door width logic
  • Key building modulations
  • Setback controls or planning envelopes
  • Maintaining consistent offsets

Examples

  • “Structural Grid Spacing”
  • “Window Head Height”
  • “Facade Module”
  • “Basement Setback Control”

Best practice:
Use for geometric consistency across the entire project where formulas must control multiple elements.

6. Family Parameters

Definition

Family Parameters exist inside the family file (.rfa).
They can be Instance or Type, but they cannot be tagged unless created as Shared.

Key Characteristics

  • Only apply inside the family
  • Good for driving geometry and formulas
  • Cannot be used outside the family
  • Ideal for controlling parametric behavior

Used For

  • Defining family geometry
  • Materials, dimensions, visibility
  • Internal calculations
  • Nested family controls

Examples

  • Door leaf thickness
  • Cabinet handle visibility
  • Panel module dimensions
  • Window sash thickness

Best practice:
Use Family Parameters for geometry logic; use Shared Parameters for any data that needs to leave the family.

7. System Parameters (Built-In)

Revit contains parameters that cannot be deleted or modified.
These include fundamental data such as:

  • Level
  • Area
  • Height
  • Volume
  • Mark
  • Type Name
  • Material
  • Fire Rating (for some categories)
  • Room Name / Room Number

They are consistent across all projects.

Best practice:
Leverage system parameters when possible instead of creating duplicates.

8. Type vs Instance Parameters

Regardless of parameter category, each parameter must be Type or Instance.

Type Parameters

  • Apply to all instances of a type
  • Good for consistent geometry
  • Avoids errors due to manual edits
  • Typically used for: dimensions, materials, repetitive values

Instance Parameters

  • Unique per placed element
  • Used for tagging, scheduling unique information
  • Ideal for: room numbers, door numbers, elevations, special attributes

General Rule

  • Geometry → Type
  • Identity Data → Instance
  • Fire, Acoustic, Thermal → Instance or Type depending on role

9. Reporting Parameters

Definition

Reporting Parameters read geometric values from the model and feed them into formulas.

Used For

  • Automatic dimension reading
  • Calculations inside families
  • Ensuring constraints remain valid
  • Parametric arrays

Examples

  • Detecting the host wall thickness
  • Measuring panel offsets
  • Driving formulas for stair geometry
  • Reading “actual” dimensions from nested elements

Best practice:
Use them to keep families adaptive and predictable.

10. Which Parameter Should Be Used When?

RequirementParameter Type
Must appear in tagsShared Parameter
Must appear across all projectsShared Parameter
Only needed in the projectProject Parameter
Needed to control geometry across buildingGlobal Parameter
Drives geometry inside a familyFamily Parameter
Used for formulas in familiesFamily or Reporting Parameter
Needed for scheduling only (not tagging)Project Parameter
Must be ISO-consistent across officesShared Parameter

11. Arcanary Best Practice Standards

1. All taggable data → Shared Parameter

Examples:

  • Window Code
  • Door Code
  • Finish Key
  • Wall Type Code
  • Fire Rating
  • Acoustic Rating

2. All classification → Shared Parameter

Arcanary taxonomy integrates:

  • Realm
  • Subset
  • Building Element Code
  • Material System
  • Documentation Status

3. Internal workflow-only fields → Project Parameter

Examples:

  • QC Notes
  • Responsibility code
  • Issue tracking fields
  • Temporary coordination notes

4. Do not create duplicate parameters

Enforce consistent shared parameter files across offices.

5. Use Global Parameters sparingly

Only for:

  • Geometry controls
  • Architectural grids
  • Facade modules
  • Standard heights

6. Use Family Parameters for geometry

Keep families lightweight and parametric.

12. Parameter Discipline in Large Projects

For multi-office or multi-disciplinary BIM:

  • Maintain one Shared Parameters File per organization (Arcanary standard)
  • Lock naming conventions
  • Add prefix codes (e.g., ARCA_, ARCH_, STR_, SERV_)
  • Perform routine audits to detect duplicate GUIDs
  • Avoid project-level parameter creation unless unavoidable

13. Common Mistakes

MistakeIssue
Overusing Project ParametersData becomes impossible to tag or reuse
Duplicating parameter namesCauses scheduling conflicts
Not naming parameters clearlyLoss of traceability
Adding Shared Parameters in local filesLeads to multiple GUID sets
Using Instance when Type is neededInconsistent modeling
Changing parameter names mid-projectBreaks schedules & tags

14. Conclusion

Parameters are one of the most powerful tools in Revit.
Understanding how each parameter type works allows the model to remain stable, predictable, and compliant with both documentation standards and Revit best practices.

By using the correct parameter category—Project, Shared, Global, Family, System, or Reporting—you ensure clean coordination, consistent schedules, accurate tagging, and long-term model integrity.