The Life Cycle of a Parameter

We need your help to develop this documentation! If you would like to contribute, please contact us.

Parameters have three states: Proposed, Approved, and Rejected. This section of the coumentation describes each state. Refer to the flow chart below for the process of proposing, approving, and rejecting parameters.


The life cycle of a shared parameter.


The first state of a parameter is the "Proposed" state.

Once a contributor proposes to add a new shared parameter to the master shared parameters list, the parameter is assign a GUID and is put in the "Proposed" state. While in this state, contributors have the opportunity to discuss the parameter using the commenting feature.

Users have the option to use this parameter immediately, even while in the proposed state. Navigate to the proposed shared parameters list and click the download button to download the list of proposed paramaters.

Download "Proposed" shared parameters at your own risk. If these parameters are deleted or modified during the review process, they may not be compatible with models that previously had the parameters loaded in.

Moderators will review the parameter against the follow criteria:

  • Follows the standard naming convention
  • Is not a duplicate (or similar) parameter to an "Approved" parameter
  • Is assigned the proper DATA TYPE
  • Contains a DESCRIPTION.

A moderator may modify the parameter to ensure compliance with these standards.

If there is some debate over the validity of the parameter, contributors may create a poll to initiate a the voting process.


If there is a unanimous decision to approve a parameter or the votes are in favor of approval, the parameter moves into the "Approved" state.

Once approved, the parameter is added to the approved shared parameters list and is included in all future downloads.

Commenting on the parameter will remain open so that if contributors require a modification, they can comment on it directly.


The third state of a parameter is the "Rejected" state.

  • It will remain in the OpenRFA database indefinitely to maintain its GUID.
  • Commenting remains open in case the community would like to vote to revise and approve the parameter.
  • A rejected parameter can go from any state to the "Rejected" state and back to the "Proposed" or "Approved" state.

The rejected shared parameters table has a column that describes the reason for the rejection. Users also have the option to download the rejected definitions file as needed.

Introducing collaborative shared parameters.

Join OpenRFA to help build the new master shared parameters for Revit.