Use variables for dynamic workflow content

Variables make your workflows respond to real data instead of using hard-coded text. When you type {{project.name}} in a task title field, the workflow replaces that token with the actual project name at runtime. You can reference data from the event that started the workflow, global date and time values, and outputs produced by earlier nodes in the same run.

How to insert a variable

In any field that supports variables, open the variable picker by clicking the {{}} button next to the field or by typing {{ directly in the field. The picker shows all variables currently available in context — including trigger data, global date values, and outputs from any nodes that have already run upstream. When you select a variable, it appears as a colored pill token in the field. The field can contain a mix of plain text and variable tokens — for example, Follow up: {{trigger.entity_data.title}} by {{global.date}} is a valid task title.

Types of variables

Trigger data

Trigger variables carry the data from the event that started the workflow. These are always available, starting from the first node after the trigger.

Variable	Available when	Example value
`{{trigger.entity_data.title}}`	All event triggers	`"Fix login bug"`
`{{trigger.entity_data.status}}`	Task triggers	`"blocked"`
`{{trigger.entity_data.priority}}`	Task triggers	`"urgent"`
`{{trigger.entity_data.payload.*}}`	Webhook trigger	Data from the POST body
`{{project.id}}`	Project and task triggers	`"proj_abc123"`
`{{project.name}}`	Project and task triggers	`"Q3 Launch"`

For webhook triggers, the full JSON body of the incoming request is accessible via {{trigger.entity_data.payload.*}}. For example, if GitHub sends {"ref": "refs/heads/main", "after": "a1b2c3"}, you reference {{trigger.entity_data.payload.ref}} and {{trigger.entity_data.payload.after}}.

Global date and time

Global date and time variables are available in every workflow, regardless of trigger type. They resolve to the current values at the moment the node executes.

Variable	Returns
`{{global.date}}`	Today’s date (e.g., `2026-03-15`)
`{{global.time}}`	Current time (e.g., `14:30`)
`{{global.datetime}}`	Full date and time
`{{global.day_of_week}}`	Day name (e.g., `Monday`)
`{{global.month}}`	Month name (e.g., `March`)
`{{global.year}}`	Four-digit year (e.g., `2026`)

Previous node outputs

Each action node that runs adds new variables to the workflow context that downstream nodes can use. Variables accumulate as execution progresses — a node can only reference outputs from nodes that have already run upstream of it in the execution order.

Variable	Available after
`{{lastTask.id}}`	A Create task node runs
`{{lastTask.title}}`	A Create task node runs
`{{lastNote.id}}`	A Create note node runs
`{{lastNote.title}}`	A Create note node runs
`{{lastHttpResponse.data}}`	An HTTP request node runs
`{{lastHttpResponse.status}}`	An HTTP request node runs

Entity pickers

For fields where you want to reference a specific item by name rather than by a dynamic variable, use the entity picker. Entity pickers let you search for and select a particular project, task, or note from your workspace. The selected item’s ID is stored as a static reference — the workflow always targets that specific item, regardless of what the trigger data contains. Entity pickers are available in fields like Target task ID and Target project ID on Update task and Update project nodes.

Variable chaining example

Variables are cumulative — each node adds to the available context for everything downstream. This example shows how a single workflow run builds up context step by step:

Trigger (project_created)
    → {{project.name}} and {{project.id}} are available

Create Note ("{{project.name}} — Kickoff")
    → {{lastNote.id}} and {{lastNote.title}} are now available

Create Task ("Set up {{project.name}}")
    → {{lastTask.id}} and {{lastTask.title}} are now available

HTTP Request
    Body: {"task": "{{lastTask.id}}", "note": "{{lastNote.id}}"}
    → {{lastHttpResponse.data}} and {{lastHttpResponse.status}} are now available

Send Notification ("Setup complete for {{project.name}}")
    → Uses project name from trigger, which is still in scope

Nested property access

Variables use dot notation to access nested properties. You can go as deep as the data structure allows.

Expression	What it accesses
`{{trigger.entity_data.title}}`	The `title` field of the trigger entity
`{{trigger.entity_data.payload.event}}`	The `event` key in a webhook payload
`{{lastHttpResponse.data.result.id}}`	A nested `id` in an API response

Which fields support variables

Not every field in every node accepts variables — some fields (like dropdowns for status and priority) use fixed values only. The table below summarizes where variables work.

Node	Fields that accept variables
Create task	Title, Description
Update task	Target task ID
Create note	Title, Content
Update note	Title, Content
Send email	To address, Subject, Body
Send Slack message	Message text
Send Discord message	Message text
HTTP request	Body
Condition	The field path to evaluate
Send notification	Title, Body
Update project	Target project ID

A variable like {{lastTask.id}} is only available after the Create task node that produces it has run. If you reference it in a node that executes before or in parallel with the Create task node, it resolves to an empty value.

Practical examples

Title that includes the triggering task’s name

Review: {{trigger.entity_data.title}}

Use this in a Create task node triggered by Note Created to automatically generate a review task named after the note.

Date-stamped daily note

Daily Focus — {{global.date}} ({{global.day_of_week}})

Use this as the title in a Create note node inside a Scheduled workflow that runs every weekday morning.

Webhook-driven deployment task

Deploy: {{trigger.entity_data.payload.ref}}

Use this as the task title in a webhook-triggered workflow that fires on GitHub pushes. The ref field in GitHub’s payload contains the branch name.

Chain output from HTTP request into a notification

Notification body: Build status: {{lastHttpResponse.data.status}}

After an HTTP request node calls your CI/CD API, reference the response data in a downstream Send notification node.

Get Started

Projects & Tasks

Notes & Files

Workflows

AI & Integrations

Changelog

Use variables for dynamic workflow content

How to insert a variable

Types of variables

Trigger data

Global date and time

Previous node outputs

Entity pickers

Variable chaining example

Nested property access

Which fields support variables

Practical examples

Title that includes the triggering task’s name

Date-stamped daily note

Webhook-driven deployment task

Chain output from HTTP request into a notification

Next steps

Nodes

Templates

​How to insert a variable

​Types of variables

​Trigger data

​Global date and time

​Previous node outputs

​Entity pickers

​Variable chaining example

​Nested property access

​Which fields support variables

​Practical examples

​Title that includes the triggering task’s name

​Date-stamped daily note

​Webhook-driven deployment task

​Chain output from HTTP request into a notification

​Next steps

Nodes

Templates

How to insert a variable

Types of variables

Trigger data

Global date and time

Previous node outputs

Entity pickers

Variable chaining example

Nested property access

Which fields support variables

Practical examples

Title that includes the triggering task’s name

Date-stamped daily note

Webhook-driven deployment task

Chain output from HTTP request into a notification

Next steps