Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.navisops.com/llms.txt

Use this file to discover all available pages before exploring further.

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.
VariableAvailable whenExample 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 triggerData 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.
VariableReturns
{{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.
VariableAvailable 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.
ExpressionWhat 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.
NodeFields that accept variables
Create taskTitle, Description
Update taskTarget task ID
Create noteTitle, Content
Update noteTitle, Content
Send emailTo address, Subject, Body
Send Slack messageMessage text
Send Discord messageMessage text
HTTP requestBody
ConditionThe field path to evaluate
Send notificationTitle, Body
Update projectTarget 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.

​
Next steps

Nodes

See which node types produce output variables and which fields accept them.

Templates

Browse starter templates that demonstrate variable usage in real workflows.