# 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](/introduction/query-manipulation/result-control.md) 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](/api-reference/users.md) 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 -> "+49 123 456789" ### 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](/introduction/assignment-and-targeting.md). 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](/api-reference/users.md) object * `entity-select` field with department entity type -> resolved\_value is a [User](/api-reference/departments.md) object * `file-upload` -> resolved\_value is [FileManagerFile](/api-reference/filemanager/filemanager-files.md) 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](/introduction/system-variables/formatters.md). ## 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](/api-reference/automation/action-types/notify.md), [task assignment titles and descriptions](/api-reference/automation/action-types/create-task-assignment.md)) * [Conditions](/api-reference/automation/conditions.md) (e.g., comparing a system variable to a specific value) * [Form field default values](/api-reference/forms/default-value-sources.md) * [Templating within form messages](/api-reference/forms/forms.md) * [Menu item configurations](/api-reference/menu/menu-items.md) --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.api.intratool.de/introduction/system-variables.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.