On this page

One of the most important features of JWT is the easy accessibility to Jira data stored in system fields, custom fields and a significant number of other virtual fields that are made available by the JWT implementation.

You can access, validate, do mathematical calculations and manipulate the values found in these fields through the use of field codes .  

A field code is a unique identifier (key) that can be used in any JWT expression editor. At the same time a field code is a safety feature that makes your expressions immune to custom field renaming.

Overview

Field codes will be automatically added to your expression when you insert them anywhere using the expression parser field code injector.

Field codes for Jira standard or system fields will display the attribute in a legible form like  %{issue.summary}.

All custom fields will be notated like  %{issue.cfnnnnn} where nnnnn contains the Jira custom field ID.

Once an expression has been saved, the real name will be displayed in the configuration element.

The purpose of using the cfnnnnn notation is quite simple -  custom fields can be renamed .


 Field code notation

Depending on the context in which they are being used, field codes will contain a prefix following this notation {origin.field}

What is a context?

A context basically determines where JWT will pull data from. Available contexts (or  origins) in JWT are:

ContextExampleDescription
issue

%{issue.description

The field value will be retrieved from the issue that currently being processed by a workflow function or automation rule.

The most commonly used context in JWT.

parent

%{parent.summary}


The field value will be retrieved from the parent of the issue that is processed by a workflow post function or an automation rule.

 Only valid for sub-tasks.

seed

%{seed.issue.summary}

%{seed.text}

%{seed.number}

The field value will be retrieved from the element currently being processed by a workflow function or automation rule that is capable of analyzing multiple elements (e.g. Create issue post function or the Create issue action).

Elements can be:

  • issues
  • texts
  • numbers

depending in your configuration. Read more about Seeds.

function

filterByPredicate(subtasks(){function.issue.dueDate} != null)

This example returns a list of all sub-tasks of the current issue that have a due date set.

The field value will be retrieved from issue(s) returned by some JWT expression parser functions.

Mostly these are functions that return an issue list (e.g. subtasks()).

Some functions iterate (loop) over all elements returned by a list. As soon as each element of the list is being processed, this element is the temporary context.

created.parent

%{created.parent.summary}

The field value will be retrieved from the new parent issue of a sub-tasks being created in a workflow post function.

Currently only available in the Create issue post function and only valid for sub-tasks.
Additional contexts for automation rules

An issue is tied to a workflow. This is why most field codes in JWT workflow functions have their issue context. Automation rules are not tied to individual issues. This is why sometimes it is necessary to define their context separately.

These additional contexts are available for automation rules:

ContextDescriptionExample
trigger The issueuser, version, component or project event that triggers the execution of the rule.

%{trigger.issue.description}

The description of the issue triggering the automation rule.

selector The  issue currently being processed by a selector  (e.g. an issue returned by a JQL query).

%{selector.issue.cf10021}

The value of the custom field with the ID 10021 from the issue currently being processed by a selector.

The  prefix  is a referential part of the field code and will be inserted into the expression whenever you select a field from a dropdown list (as shown below).   

The additional contexts can be used in combination with the standard contexts (e.g. parent, seed).

Example: %{trigger.parent.summary}

Find a full list of automation-only field code here: Field codes (automation-only)

Number vs. text field code notation

Field codes must always be enclosed by curly brackets {} but if they are used for text-strings, the brackets must be preceded by a percent sign %

  • Numeric fields can be referenced as numbers using the following notation: {issue. somenumberfield }. ((info) no preceding % sign)
    • If a field is not set or does not return a number (e.g. a text field ), it is evaluated to null .
  • Text fields : Any field type or data type can be transformed to text, so any field can be referenced as a text-string value using the following notation: %{issue.somefield}.
    • If a field has no value ( null) , an empty text will be returned.
  • Cascading Select fields are treated as text fields, where i is the index that represents the level to be accessed. ( i = 0 is used for base level) are notated as %{issue.somefield.i}

A complete list of all available data types can be found here.


Available field codes

Check out the following pages to familiarize yourself with the different types of field codes.


If you still have questions, feel free to refer to our support team.