Word Template — Token Reference — Help

The complete list of data paths (bindings) you can use in a Word template. This mirrors the in-product token reference panel and the binding catalog the validator enforces — if a path is not listed here, the template editor flags it. For grammar and formatters see word-template-mode.md; for Xporter-style syntax see word-template-xporter-unsupported.md.

i18n note: This page is EN-first. The German translation follows with the next localization pass — no code change is required to ship DE.

How to read this page

A scalar binding is used in a value token: ${issue.summary}.
A collection binding is used in a loop: ${#each issue.subtasks as sub}…${/each}. Inside the loop, reach an item field via the loop variable: ${sub.key}.
Tiers: A ships in V1.1; B ships only because the issue bundle already carries the data; C is visible but not bindable in V1.1 (deferred to V1.2+) — listed so the product is honest about scope.
Which roots are available depends on the export context (below). Using a root that is not in your context is flagged.

Export contexts and their roots

A Word template runs in one of seven contexts. Each exposes a different set of top-level roots.

Context	Available roots
`single-issue`	`issue`, `generatedAt`
`automation` (Jira Automation action, acts on the triggering issue)	`issue`, `generatedAt`
`multi-issue` (JQL / board)	`issues`, `issueGroups`, `generatedAt`
`scheduled` (sister-app scheduled export)	`issues`, `issueGroups`, `generatedAt`
`sprint`	`issues`, `issueGroups`, `sprint`, `generatedAt`
`release`	`issues`, `issueGroups`, `release`, `generatedAt`
`backlog`	`issues`, `issueGroups`, `backlog`, `generatedAt`

generatedAt (a datetime) is available in every context.

Tier A — the issue surface (`issue.*`)

Available in single-issue and automation. The same fields are also the per-item shape of the issues collection (below) — inside ${#each issues as it} use ${it.key}, ${it.summary}, and so on.

Scalars

Path	Type
`issue.key`	string
`issue.summary`	string
`issue.description`	rich text (ADF)
`issue.status`	status
`issue.status.category`	string
`issue.priority`	priority
`issue.assignee`	user
`issue.assignee.displayName`	string
`issue.reporter`	user
`issue.reporter.displayName`	string
`issue.created`	datetime
`issue.updated`	datetime
`issue.dueDate`	date
`issue.parent.key`	string
`issue.parent.summary`	string
`issue.parent.status`	string

A user-typed value renders the display name by default; use the user formatter to pick a part, e.g. ${issue.assignee | user("displayName")}. A rich-text (ADF) value renders formatted; use | plain() to strip formatting.

Collections (use in `${#each …}`)

Collection	Item fields (relative to the loop variable)
`issue.labels`	primitive list — the loop variable is the label string
`issue.components`	`name`
`issue.fixVersions`	`name`, `released` (boolean)
`issue.affectsVersions`	`name`
`issue.subtasks`	`key`, `summary`, `status`, `priority`, `assignee`, `dueDate`
`issue.comments`	`author` (user), `author.displayName`, `body` (ADF), `created`, `updated`
`issue.attachments`	`filename`, `mimeType`, `size` (number), `isImage` (boolean), `created`, `author.displayName` — metadata only (no binary, no URL)
`issue.issueLinks`	`typeName`, `direction`, `linkedIssue.key`, `linkedIssue.summary`, `linkedIssue.status`
`issue.worklogs`	`author.displayName`, `timeSpent`, `timeSpentSeconds` (number), `created`, `started`

Example:

${#each issue.worklogs as wl}
${wl.author.displayName}: ${wl.timeSpentSeconds | duration("hm")} on ${wl.started | date("yyyy-MM-dd")}
${/each}

Tier A — multi-issue roots

Available in multi-issue, scheduled, sprint, release, backlog.

Path	Kind	Item fields
`issues`	collection	the full issue surface (all the `issue.*` fields above, relative to the loop variable)
`issueGroups.fixVersions`	collection	`key`, `title`, `issues` (sub-collection)
`issueGroups.sprints`	collection	`key`, `title`, `issues` (sub-collection)
`issueGroups.assignees`	collection	`key`, `title`, `issues` (sub-collection)
`issueGroups.worklogAssignees`	collection	`key`, `title`, `issues` (sub-collection)

Example (group, then issues within each group):

${#each issueGroups.assignees as group}
## ${group.title}
${#each group.issues as it}
- ${it.key}: ${it.summary}
${/each}
${/each}

Tier A — context bundle roots

Only available in their own context.

`sprint`

Path	Type
`sprint.sprint.name`	string
`sprint.sprint.goal`	string
`sprint.sprint.state`	option
`sprint.stats.issueCount`	number
`sprint.stats.percentDone`	number

`release`

Path	Type
`release.release.name`	string
`release.release.releaseDate`	date
`release.release.released`	boolean
`release.stats.issueCount`	number
`release.stats.percentDone`	number

`backlog`

Path	Type / item fields
`backlog.board.boardName`	string
`backlog.board.boardType`	option
`backlog.stats.totalIssueCount`	number
`backlog.groups`	collection — `kind` (option), `name`, `issueCount` (number), `issues` (sub-collection)

Tier A — metadata

Path	Type	Contexts
`generatedAt`	datetime	all

Tier B — changelog

Ships in V1.1 only because the issue bundle already carries it.

Path	Kind	Item fields
`issue.changeHistory`	collection	`author.displayName`, `created`, `items` (sub-collection)

Tier C — visible but not bindable in V1.1

These exist conceptually but are not resolvable in V1.1; they are listed so the editor and validation can be honest about scope. They are deferred to V1.2+.

Capability	Note
`issue.jsm`	Jira Service Management request/SLA/approval surface — deferred to V1.2.
JQL-in-template	Detected by the migration scanner and diagnosed, never executed.
Tempo	A Tempo mirror may exist on a worklog, but is not bound in V1.1.
Xray / Zephyr	Test-management fields require a third-party app (V1.2+).
Assets / Insight	Object fields are deferred to V1.2.

Custom fields

Custom fields are bindable under a single namespace:

${ issue.customFields.<fieldId>.<…> }

Unknown custom-field ids are soft: the editor shows a warning (the value may render empty), never a hard block — so a template can reference a field this site happens not to have without failing.
The bare path issue.customFields (the whole map) is never bindable.
Only safe identifier characters are allowed; __proto__, prototype and constructor segments are rejected.

Honesty caveats when migrating from Xporter

The migration scanner suggests Exportelier paths for common Xporter field names. Two things to know so a suggested rewrite actually resolves:

Auto-conversion fixes the syntax, not the existence of a path. A suggested rewrite is the right shape, but the target must still be a real binding on this page, or it produces an unknown-binding warning:
- Not in the catalog at all: Creator → issue.creator, Resolution → issue.resolution, Project → issue.project, IssueType / Type → issue.issuetype. None of these is a Tier-A binding in V1.1.
- Case mismatch: DueDate is suggested as issue.duedate, but the binding is issue.dueDate (capital D).
- Kind mismatch: Labels is suggested as a scalar ${issue.labels}, but issue.labels is a collection — use a loop: ${#each issue.labels as l}….
Issue links. The collection alias Links is suggested as links, but the real binding is issue.issueLinks. Use ${#each issue.issueLinks as l}….

See word-template-xporter-unsupported.md for the full migration map.

Paths that are never allowed

For safety, some paths are rejected with an unsafe-template error regardless of context — internal, credential or URL-bearing fields. These include roots such as auth, context, forge, internal, secrets, storage, token, and any path ending in accountId, apiToken, avatarUrl, baseUrl, contentUrl, thumbnailUrl, cookie, session, headers, private or storageRef. Stick to the bindings on this page and you will not hit these.