Skip to main content

Use Dynamic Fields

Learn how to use dynamic fields and its associated markup, letting you reference values stored in other properties and custom fields.

Written by Cutover Documentation Team

Dynamic fields markup is a powerful way to reference values contained in other runbook and task properties (including standard fields) and custom fields.

This interpolated referencing - including Runbook, Task, and Workspace properties - can be used:

  • In runbook level custom fields (text type only)

  • For task name (with limited formatting options)

  • In task level custom fields (text type only)

  • In a message body in email task type

For example, if you had an integration with Jira that created a new Jira bug that was stored in a custom field, a proceeding task’s title could be set up to fully reference the Jira bug once it had been created.

Dynamic fields markup

Referencing properties

The markup is {{variable_name.property_name}}.

As an example, this is what it can look like in an email task type:

The recipient of the email reads it with the interpolated references as follows:

Referencing custom fields

The markup is {{CustomField['custom field name']}} to reference any runbook-level custom fields, or when referencing a task’s own custom field values.

The markup differs if you wish to reference a custom field value belonging to another task in the runbook.

Note: Any single-value custom field type can be referenced through dynamic fields markup. These types are:

  • Text

  • Textarea (note any formatting will show as html when referenced)

  • Select Menu (single-select)

  • Radio Box (single-select)

  • Checkboxes (multi-select) this only works for single values.

  • Date

  • User Select (multi-select) - this only works for single values and will display a users email address.

As an example, this is what referencing a custom field looks like in the task editing panel. When the referencing custom field is clicked on (is focused), the raw markup is shown:

When the custom field isn’t focused (isn't clicked on), the computed value is displayed:

If you hover over the code icon (< / >) to the right, it will display the custom field that is being referenced:

Referencing task-level custom field values belonging to another task

The markup is {{CustomField['custom field name###1']}}.

It differs to referencing runbook-level custom fields by adding ### followed by a task’s internal ID. In the above example, it’s referencing a custom field value that lives on a task with an internal ID of 1.

Note: You can also reference task-level custom fields within the current runbook through a JSONPath lookup. See Referenceable variables for more detail.

Referencing task-level custom fields in runbook-level custom fields

You can reference a task-level custom field from a runbook-level text custom field using the following syntax:

{{CustomField['custom field name###TaskID']}}

Where custom field name is the name of the task-level custom field and TaskID is the task's internal ID.

For example:

{{CustomField['Migration Status###12']}}

If the Migration Status custom field on task 12 contains the value Complete, the runbook-level custom field will resolve to:

Complete

Note: When referencing a custom field from another task, use the task's internal ID after ###. The internal ID is not the task name or the task's position in the runbook.

The referenced task must exist within the same runbook, and the custom field name must match exactly, including spaces and capitalisation.

Using Dynamic Fields with Credentials

Dynamic fields do not support referencing values stored as Temporary Credentials. If you attempt to use dynamic field markup to reference a custom field of type Temporary Credential, the value will not resolve at runtime.

If you need to reference an API key, token, or similar static secret (for example, a Jules API key), we recommend using System Parameters instead. System parameters are designed for securely storing values that need to be reused across integrations and support dynamic field referencing.

Note:Temporary Credentials are intended for short-lived, frequently rotated secrets and are not compatible with dynamic field resolution.

Dynamic syntax in runbook titles

Dynamic syntax used in runbook titles is preserved when:

  • Duplicating a runbook

  • Bulk duplicating runbooks

  • Creating a runbook from a template

  • Creating a runbook from a master template

This allows references such as Searchable Custom Fields to continue resolving correctly without requiring the syntax to be re-entered.

Restrictions

  • Dynamic fields can only reference properties and fields that exist within the current runbook you’re working with. Other runbooks’ properties and fields cannot be referenced.

  • A task can only reference the values of its own properties; it cannot reference the values of properties belonging to other tasks. However, you can reference task-level custom field values belonging to another task in the same runbook (see CustomField in the Referenceable variables table for the markup).

  • When merging runbooks, references to the runbook will mean referencing the source runbook. You cannot reference more than one runbook.

Duplicating completed runbooks that contain referencing custom fields

Any custom fields that reference another property or custom field get resolved to actual values once a runbook’s live run has completed. This means that any referencing markup (for example, {{CustomField['Task status']}}) is removed and fully replaced with the referenced value (for example, Complete).

This has an implication when duplicating runbooks. When you duplicate a completed runbook, the runbook will duplicate the resolved values only, as opposed to any referencing markup. However, duplicating in-planning runbooks will duplicate the markup.

Referenceable variables

Variable

Lookup

Description

Runbook

Any runbook property, such as id, name, or description (see table of referenceable Runbook properties).

Example: {{Runbook.description}}

This returns the property value for the runbook.

Task

Any task property, such as id, internal_id or name (see table of referenceable Task properties).

Example: {{Task.id}}

This returns the property value for the task.

Workspace

Any workspace property, such as id, name, or shortname (see table of referenceable Workspace properties).

Example: {{Workspace.name}}

This returns the property value for the workspace.

CustomField

Any runbook-level custom field or a task referencing any of its own custom fields - {{CustomField['custom field name']}}

Any task-level custom fields belonging to another task in the runbook - {{CustomField['custom field name###1']}}

Example: if the custom field to be referenced is called ‘Assignee’ and belongs to another task with an internal ID of 3, the syntax would be {{CustomField['Assignee###3']}}

This returns the value of a custom field associated with a runbook or task. Custom fields that cannot be accessed by the task will be ignored. Custom fields must match their name, including case and spaces.

JSON

Any of several objects serialised to be referenced using JSONPath syntax. For full documentation on this, see the ‘Using JSONPath lookups’ section in our Developer Portal’s Custom Integration page.

Example:{{JSON["$.task_custom_field_values.2.'custom field name'"]}}

This returns the value of the referenced object or object property.

Referenceable properties

Runbook properties

id

name

description

archived

status

runbook_version_id

author_id

project_id

created_at

updated_at

runbook_type_id

parent_version_id

account_id

event_id

is_template

template_status

template_next_review

copies_count

settings_team_in_task_list

timezone

settings_substreams_inherit_color

status_message

status_updated_at

status_author_id

template_type

rta (in seconds)

rto (dd:hh:mm:ss) depending on input

runbook.start_actual

runbook.end_actual

runbook.start_planned

runbook.end_planned

Task properties

id

name

start_planned

start_fixed

start_ready

start_actual

end_actual

duration

prev_task_type

start_requirements

end_requirements

internal_id

author_id

description

message

runbook_version_id

stream_id

created_at

updated_at

comments_count

decision_status

decision_notes

start_forecast

start_forecast_offset

in_progress_duration

task_type_id

level

completion_type

completion_meta

start_type

fixed_start_type

disable_notify

source_internal_id

runbook_component_id

end_fixed

current_integration_event_id

Workspace properties

id

name

shortname

Did this answer your question?