> For the complete documentation index, see [llms.txt](https://docs.heeler.com/mrecEO40m5D6bt7Pq5pE/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.heeler.com/mrecEO40m5D6bt7Pq5pE/reference/workflow-template-variables.md).

# Workflow Template Variables

How variables work inside workflow message and ticket templates — the syntax, the fields you can reference, the shared variables, and the helpers for turning names into Slack and Jira mentions.

[Workflow](/mrecEO40m5D6bt7Pq5pE/operate/workflows.md) messages, emails, and tickets are **templates** — you write the wording once and let variables fill in the specifics of each event. This page covers the syntax and the variables you can reach.

## Syntax

Templates use Jinja2. A variable is an expression in double braces, and you can pipe it through standard Jinja filters:

```jinja
🚨 {{ data.vulnerability.severity }} — {{ data.finding.package_name }}
{{ data.vulnerability.title }}

Fix: upgrade to {{ data.vulnerability.fixed_versions | join(', ') }}
{{ data.finding.url }}
```

Two things make templates forgiving to write:

* **A missing value renders blank** rather than erroring, so a template that references a field an event doesn't have still sends.
* **The context is available two ways** — at the top level (`{{ resource.full_name }}`) and under `data` (`{{ data.resource.full_name }}`). The builder's picker inserts whichever form that trigger's defaults use, so the simplest approach is to insert from the picker rather than typing paths by hand.

## Which variables are available

The variables you can reference depend on the workflow's **trigger** — a secret trigger exposes `secret.*`, a SAST trigger exposes `sast_finding.*`, and so on. The complete per-trigger catalog is on its own page:

{% content-ref url="/pages/8sIJBiQfqayv9cac0qXc" %}
[Workflow Trigger Data Elements](/mrecEO40m5D6bt7Pq5pE/reference/workflow-trigger-data-elements.md)
{% endcontent-ref %}

In the builder, the variable picker lists exactly what's available for your chosen trigger and inserts the correct expression — the surest way to get the path right.

## Shared variables

Beyond the trigger-specific fields, every template can reference the [common data elements](/mrecEO40m5D6bt7Pq5pE/reference/workflow-trigger-data-elements.md#common-data-elements): `workflow_name`, `workflow_id`, `workflow_execution_id`, and `tenant_id`.

### Referring to an earlier step

A workflow's [actions](/mrecEO40m5D6bt7Pq5pE/operate/workflows/actions.md) run in order and share one context, so a later step can template the result an earlier step produced — the concept and worked examples live under [Chaining actions](/mrecEO40m5D6bt7Pq5pE/operate/workflows/actions.md#chaining-actions). This section is the variable reference behind it.

**Ticket aliases.** The most recently created ticket is always available at `created_ticket`, and every ticket created in the run is collected in `created_tickets`:

<table><thead><tr><th width="320">Variable</th><th>Description</th></tr></thead><tbody><tr><td><code>created_ticket.key</code></td><td>The key of the most recently created ticket (e.g. <code>PROJ-123</code>, <code>ENG-123</code>, <code>acme/api-service#123</code>)</td></tr><tr><td><code>created_ticket.url</code></td><td>Its URL</td></tr><tr><td><code>created_ticket.provider</code></td><td>Which tracker created it (jira / linear / github)</td></tr><tr><td><code>created_tickets</code></td><td>The list of all tickets created so far this run, to iterate over</td></tr></tbody></table>

So a two-step workflow — *Create Jira Issue*, then *Send Slack Message* — can announce the ticket it just filed:

```jinja
Filed {{ created_ticket.key }} for {{ data.finding.package_name }} → {{ created_ticket.url }}
```

**By step.** Any create-style step's output is also addressable by the step's position — `action_0`, `action_1`, and so on. Reach it with **bracket access** (a step id isn't a valid dotted name):

<table><thead><tr><th width="360">Variable</th><th>Description</th></tr></thead><tbody><tr><td><code>actions['action_0'].key</code> / <code>.url</code></td><td>A ticket opened by the first action</td></tr><tr><td><code>actions['action_0'].pr.url</code></td><td>The pull request from a <strong>Fix with Heeler Agent</strong> step — also <code>.pr.title</code> and <code>.pr.branch_name</code></td></tr><tr><td><code>actions['action_0'].status</code></td><td>A Fix with Heeler Agent step's status</td></tr></tbody></table>

```jinja
✅ Auto-fix opened → {{ actions['action_0'].pr.url }}
```

{% hint style="info" %}
When a **Fix with Heeler Agent** action is followed by a notify action, the workflow pauses until the pull request reaches an outcome before running the notify step — so the PR fields above are populated by the time your message renders.
{% endhint %}

## Helpers

A couple of helpers turn Heeler identities into platform-native mentions, so notifications actually ping the right person:

<table><thead><tr><th width="360">Helper</th><th>Description</th></tr></thead><tbody><tr><td><code>utils.get_slack_member_id(...)</code></td><td>Resolves a user to their Slack member ID, for an <code>&#x3C;@ID></code> mention in a Slack message.</td></tr><tr><td><code>utils.get_jira_user_id(...)</code></td><td>Resolves a user to their Jira account ID, for assignment or mention in a Jira issue.</td></tr></tbody></table>

## Template fields by action type

Which fields a template carries depends on the action it's for:

<table><thead><tr><th width="300">Action type</th><th>Template fields (all Jinja)</th></tr></thead><tbody><tr><td>Slack / Teams / Google Chat</td><td>Message</td></tr><tr><td>Email</td><td>Subject, Body (HTML)</td></tr><tr><td>Jira / Linear / GitHub / Shortcut</td><td>Summary, Description, and field defaults</td></tr></tbody></table>

Heeler ships default templates for every trigger-and-integration pair, so you rarely start from a blank box — see [Routing and Templates](/mrecEO40m5D6bt7Pq5pE/operate/workflows/routing-and-templates.md) for how templates are chosen and overridden.

## Related

* [Workflow Trigger Data Elements](/mrecEO40m5D6bt7Pq5pE/reference/workflow-trigger-data-elements.md) — the full field catalog per trigger.
* [Routing and Templates](/mrecEO40m5D6bt7Pq5pE/operate/workflows/routing-and-templates.md) — choosing, customizing, and overriding templates.
* [Actions](/mrecEO40m5D6bt7Pq5pE/operate/workflows/actions.md) — the messaging and ticketing actions templates apply to.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## 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, and the optional `goal` query parameter:

```
GET https://docs.heeler.com/mrecEO40m5D6bt7Pq5pE/reference/workflow-template-variables.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.