System Variables

System variables are a powerful feature that allow you to access dynamic data within your automation workflows. They can be used within rich text fields, conditions, prefilling form fields, and even menu items, providing context-aware information that can enhance the functionality of your automations.

Always available system variables

- `system.date`
- `system.temporaryUser`
- `system.user`

Context types and available system variables

Depending on the context, different system variables are available. These variables can include information about the current user, the date, and specific details related to the triggering event (e.g., form message details, task execution details).

ContextType	available when...	Available System Variables
AttributeSet	a default value for an attribute is chosen	attributeSet
EntitySelect	an entity selection from a field of type entity_select is resolved	selectableEntity (User or Department, depending on entity type)
Form	a default value for a field is chosen	form
FormMessage	a form is being submitted	formMessage, form, field.{formFieldKey} + field.{formFieldKey}.value, field.{formFieldKey}.request_value, field.{formFieldKey}.resolved_value
MenuItem	a menu item is being rendered	menuItem
TaskAssignment	a task assignment context is evaluated	taskAssignment
TaskExecution	a task has been finished	taskExecution, field.{formFieldKey} + field.{formFieldKey}.value, field.{formFieldKey}.request_value, field.{formFieldKey}.resolved_value

Accessing properties and childen

The available system variables differ based on the context in which they are accessed. The above variables are entry points to access more specific information. For example, system.user can provide access to the current user's details such as system.user.id, system.user.email, etc. Similarly, in a FormMessage context, you can access specific form field values using the field.{formFieldKey} syntax.

Please refer to the documentation of the given object types to understand the specific properties and relations available for the system variables in that context. If for example you see that a user has the relation role, you can access the user's role properties via system.user.role.property (e.g. system.user.role.name for the role name).

Understanding the structure of the objects that system variables represent is key to effectively utilizing them in your automations. This knowledge might also be used when applying the concept of Result control to any kind of endpoint.

Syntax

To access system variables, you can use the following syntax:

{{ systemVariableKey }}

To access specific properties or relations of a system variable, you can use dot notation:

{{ systemVariableKey.property }}

{{ systemVariableKey.relation.property }}

In some cases where only the system variable key is evaluated the braces can be omitted, for example when using system variables as computed targetables.

Examples

key	description
system.date	Current date/time context object. Example access: {{ system.date }} or nested properties depending on formatter/context.
system.user	Current authenticated user. Example: {{ system.user.id }}, {{ system.user.role.name }}.
system.temporaryUser	Temporary authenticated user (if available in current context). Example: {{ system.temporaryUser.id }}.
form	Current form context object (where available). Example: {{ form.name }}.
formMessage	Submitted form message object in FormMessage context. Example: {{ formMessage.id }}.
taskAssignment	Task assignment object in TaskAssignment context. Example: {{ taskAssignment.title }}.
taskExecution	Task execution object in TaskExecution context. Example: {{ taskExecution.id }}.
attributeSet	Attribute set object in AttributeSet context. Example: {{ attributeSet.title }}.
menuItem	Menu item object in MenuItem context. Example: {{ menuItem.id }}.
selectableEntity	Selected entity in EntitySelect context (user or department). Example: {{ selectableEntity.id }} or {{ selectableEntity.name }}.
field.{formFieldKey}	Full field context object in FormMessage and TaskExecution contexts. Use this when you need structured access to the field.
field.{formFieldKey}.value	Raw stored field value (usually normalized to the persisted representation). Useful for direct comparisons.
field.{formFieldKey}.request_value	Original value from the incoming request before full resolving/formatting. Useful for debugging or strict input-based logic.
field.{formFieldKey}.resolved_value	Final resolved/rendered value after processing (e.g. formatting, entity resolution). Useful for output-ready text and notifications.
system.user.role.additional_attributes.{attributeSetKey}.{attributeFieldId}	Access an additional attribute that is linked to the current user's role. Without sub-key, this resolves to the field value (same behavior as field.*).
system.user.role.additional_attributes.{attributeSetKey}.{attributeFieldId}.value	Stored value of a role-bound additional attribute field (normalized output value).
system.user.role.additional_attributes.{attributeSetKey}.{attributeFieldId}.request_value	Original request value of a role-bound additional attribute field.
system.user.role.additional_attributes.{attributeSetKey}.{attributeFieldId}.resolved_value	Resolved/rendered value of a role-bound additional attribute field.
system.user.role.department.additional_attributes.{attributeSetKey}.{attributeFieldId}	Access an additional attribute that is linked to the current user's department. Without sub-key, this resolves to the field value.
system.user.role.department.additional_attributes.{attributeSetKey}.{attributeFieldId}.value	Stored value of a department-bound additional attribute field (normalized output value).
system.user.role.department.additional_attributes.{attributeSetKey}.{attributeFieldId}.request_value	Original request value of a department-bound additional attribute field.
system.user.role.department.additional_attributes.{attributeSetKey}.{attributeFieldId}.resolved_value	Resolved/rendered value of a department-bound additional attribute field

Resolving field values

From the last of the above examples you can see that there are different ways to access values of a field. Let's say you have a field of type text with the form field id 123 and the field has the value "Max".

• field.123 -> "Max"

• field.123.value -> "Max"

• field.123.request_value -> "Max"

• field.123.resolved_value -> null

Accessing the field via field.123 or field.123.value gives you the same result, which is the stored value of the field.

Let's say you have a field of type entity-select that allows the selection of a user and the form field id is 456. The user with the id 789 and the name "Max Mustermann" is selected.

• field.456 -> "Max Mustermann (Omnis Dolor Incidunt, ID: 789)"

• field.456.value -> "Max Mustermann (Omnis Dolor Incidunt, ID: 789)"

• field.456.request_value -> 789

• field.456.resolved_value -> Object of type User

Since resolved_value in the above case in an object you might as well access specific properties of the resolved user:

• field.456.resolved_value.phone -> "[phone]"

When to use resolved_value

When used in string context, resolved_value might not be used directly because the resolved object cannot be rendered directly. In those cases value or request_value make more sense or you access properties of the underlying object like in the above example with the phone number. However, it makes sense to use resolved_value when using system variables within dynamic assignments.

Depending on the field type these object types can be expected as resolved values:

• entity-select field with user entity type -> resolved_value is a User object

• entity-select field with department entity type -> resolved_value is a User object

• file-upload -> resolved_value is FileManagerFile object All other field types provide null as resolved_value.

Additional parsing

When a system variable is rendered it may be passed through a formatter.

What if a system variable is not available or cannot be accessed?

During rendering the variable will be replaced with an empty string.

Where can I use system variables?

System variables can be used in various places within your automation workflows, including:

• Action configurations (e.g., notification titles and bodies, task assignment titles and descriptions)

• Conditions (e.g., comparing a system variable to a specific value)

• Form field default values

• Templating within form messages

• Menu item configurations