Skip to content

Parameters

Parameter objects represent shared parameter definitions registered in the Revit model. They are separate from the parameter values on individual elements — a Parameter object describes the parameter itself (its name, GUID, and binding), not a value.


The Parameter object

{
  "id": 802341,
  "type": "Parameter",
  "name": "NLRS_C_kwaliteitsklasse_code",
  "parent": null,
  "values": {
    "guid": "73803e29-3501-4c39-8c13-a49c4f2259d3",
    "isProjectParameter": false
  }
}

Key fields:

Field Description
name Display name of the shared parameter
values.guid The unique identifier that links this definition to parameter values on elements
values.isProjectParameter true = added directly to the project; false = added via a family

Basic filter — list all shared parameters

$[type = "Parameter"].{
  "id": id,
  "name": name,
  "guid": values.guid,
  "isProjectParameter": values.isProjectParameter
}

Use this as an audit query to see which shared parameters are present in the model.


Filtering by source

To audit only parameters that came in via families (the most common source of naming or GUID drift):

$[type = "Parameter" and values.isProjectParameter = false].{
  "id": id,
  "name": name,
  "guid": values.guid
}

To audit project-level parameters:

$[type = "Parameter" and values.isProjectParameter = true].{
  "id": id,
  "name": name,
  "guid": values.guid
}

Building a GUID lookup table

The most common use of Parameter objects in production rules is to build a lookup table that maps logical parameter names to their GUIDs. This is then used to read shared parameter values from elements.

(
  $paramGuids := {
    "NLRS_C_kwaliteitsklasse_code": "73803e29-3501-4c39-8c13-a49c4f2259d3"
  };

  $paramMetaByGuid := $merge(
    $$[type = "Parameter" and values.guid in $paramGuids.*].{
      $string(values.guid): {
        "guid": values.guid,
        "name": values.name
      }
    }
  );

  /* $paramMetaByGuid is now a map: { "73803e29-...": { guid: ..., name: ... } } */
  $paramMetaByGuid
)

The $paramGuids object defines the logical names and their expected GUIDs. Filtering Parameter objects to only those GUIDs ensures the lookup table is built from the actual parameters present in the model.


Why Parameter objects exist separately

Shared parameter values on elements are stored as p_<guid> keys inside values. For example:

{
  "id": 616521,
  "type": "FamilyInstance",
  "values": {
    "p_73803e29-3501-4c39-8c13-a49c4f2259d3": {
      "hasValue": true,
      "value": "S355",
      "valueAsString": "S355"
    }
  }
}

The Parameter object provides the human-readable name (NLRS_C_kwaliteitsklasse_code) for that GUID key. Without looking up the Parameter object, the raw key is opaque.


Common mistakes

  • Confusing Parameter objects with parameter values — Parameter objects are definitions, not values
  • Filtering type = "Parameter" without $$ when inside a nested function scope — use $$[type = "Parameter"] to reach the full dataset
  • Assuming every expected Parameter object exists — a shared parameter definition is only present if the parameter has been added to at least one element in the model