Skip to content
Go to platform

Last updated:

Variables

Variables let administrators define reusable values within a collection, making configurations more flexible and reducing hardcoded values across forms, filters, dashboards, and navigation flows. The platform supports two types, both scoped per collection: static variables and collection variables.

Static variables store values that don’t change often but should stay configurable, such as company GUIDs used in REST node calls, API endpoints, a fixed year used in filters, or configuration flags. They’re managed on the Variables page, can be edited at any time, and changes apply immediately to all new executions and usages. A static variable has one fixed value set by administrators.

Collection variables are user-specific and store contextual information per user, such as external system IDs (for example an AFAS employee ID or Exact res_id), an employee type, an approval flag, or conditions for form visibility or button access. Their value is resolved based on a defined hierarchy: see Collection variable hierarchy below.

Every variable has a name, a description, and a type (Text, Numeric, Fraction, or Boolean). Static variables additionally have a fixed value; collection variables additionally have an editable by user setting, which determines whether users may change their own value.

When a collection variable isn’t set directly on the user, its value is resolved using this precedence, from highest to lowest:

  1. Personal: if set directly on the user, this value is always used.
  2. Authorisation structure: if multiple structure levels define the variable, the value closest to the root node is used; higher-level nodes override lower-level ones.
  3. Authorisation group: based on sort order; the first group with a value is used.
  4. Direct role assignment: based on role sort order; the first role with a value is used.

If no level defines a value, the variable resolves to null.

Variables can be used as filter values, as values in form nodes, as fixed filters on dashboards and forms, in navigation flows, and in integrations such as REST node calls. Depending on where you configure them, you either pick a variable from a dropdown or reference it manually.

Manual references use the format {@variableName}, for example {@companyId}.

A static variable named companyId (type Text) with value 8f9c2d41-6a11-4e6e-98ab-112233445566 can be used in a REST node as:

/api/orders?companyId={@companyId}

A collection variable named employeeType (type Text, not editable by user) might hold values like Welder, Finance, or IT. A form’s filter field can then reference {@employeeType} to show certain fields only when it equals IT: giving you dynamic, per-user behavior without changing the authorisation structure itself.

  • Use static variables for configuration-like values (GUIDs, endpoints, fixed years).
  • Use collection variables for user-specific behavior or external references.
  • Keep variable names clear and descriptive.
  • Avoid relying on deep hierarchy overrides when not necessary.
  • Document variable usage clearly within the collection to prevent conflicts.