On this page

One of the main features of JWT for Jira Cloud is the easy access to Jira data through the use of field codes.

Depending on the selected Parsing mode, the available field codes will vary. Custom fields are shown if they are defined for a global context or if the "Jira Workflow Toolbox Cloud" user has browse permissions for the respective project.

JWT field codes are currently available to be used in post functions with the following Parsing modes:

Jira expressions use the Jira expression parsing mode and a different set of field codes. They can be used in post functions as well as in the Jira expression condition/validator.

If you want to include Jira expression field codes in the General mode or the Logical mode, simply use the JWT expression parser function jiraExpression(), e.g. %{jiraExpression(issue?.sprint?.endDate)} to get the end date of the sprint (this field is not available as JWT field code).

General information about JWT field codes

Field code notation

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

Available contexts (or origins ) in JWT for Jira Cloud are:

ContextDescription

issue

The issue that is processed by the workflow post function

parent

The parent of the issue that is processed by the workflow post function - if available
seed

The field value will be retrieved from the element currently being processed by a workflow function capable of handling multiple elements (e.g. Create issue post function).

Elements can be:

  • texts
  • numbers
  • issues

depending on your configuration. Read more about seeds.

system

Some data does not have an issue context (e.g. the currently logged in user or the system date and time)
actionThis field code context is only available in the post function Execute remote action. It is used to access data which is returned by the executed action.


The prefix, denoting the origin (where the data should be read from / written to), is a referential part of the field code and will be inserted into the expression whenever you select a field from a drop-down list.

Here are some examples:

Field codeOutput

%{issue. description}

The description of the current issue

%{parent.summary}

The summary of the parent issue

%{issue.project.lead}

The project lead of the project the issue belong to
%{seed.issue.summary}

The summary of the current element of the issue list when using the mode "Multiple issues based on an issue list"

%{seed.text } The text of the current element of the text list when using the mode "Multiple issues based on a text list"
%{seed.number } The value of the current number when using the mode "Multiple issues based on a number"

%{system.currentUser}

The current user (executing the post function)
%{action.status}The status of the action that was executed in the post function Execute remote action.


Numbers vs Text

Field codes must always be enclosed by curly brackets. If they are used for texts, 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 the field is not set or doesn't return a number (e.g. if the issue summary equals "Issue's summary" and you enter {issue.summary} ), 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 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}


For some fields not only their value can be returned, but also the respective ID. This ID is typically used when writing a field value, but it can also be used when reading a field value.

If a custom field is able to return an ID it can be accessed using the field code %{somefield.id} . The column ID in the lists below shows a value for the respective field, if applicable.

Available JWT field codes

  • Issue related fields can belong to an issue or it's parent . In case you want to retrieve the value of the parent issue, " issue " has to be replaced "parent " as in %{parent.summary} . In case, a field is not set (or even non-existent), this field is evaluated to null , i.e. an empty text.
  • The field codes for all custom fields are notated in the following format: %{issue.cfnnnnn}, where nnnnn contains the Jira custom field ID.
  • If Jira Software is installed on your Jira instance, you can retrieve the data stored in the Jira Software related field with Jira Workflow Toolbox for Jira Cloud as well. You can access those, like any other custom field in your instance, i.e. %{issue.cfnnnn}, where nnnnn contains the Jira custom field ID .
  • Writable fields can be updated by JWT for Jira Cloud post functions . All writable fields are also readable.
  • The field codes for all custom fields are notated in the following format: %{issue.cfnnnnn}, where nnnnn contains the Jira custom field ID.

Please note that the field you want to set must be located on the corresponding screen and the executing user must have all the necessary permissions and access to the issue.

General information about Jira expression field codes

All fields, methods and operators listed for the Jira eypression field codes have been taken from the official documentation and cannot be extended by JWT for Jira Cloud.

In the list we use optional chaining to avoid errors when trying to access field values of null objects. In case a field is not set, null is returned for the respective attribute, e.g. issue?.resolution?.name will return null in case the resolution is not set. Without the optional chaining an error will be returned.

If a .map() function is used as field code (e.g. issue?.links?.map(link => link.linkedIssue.key) for Keys of linked issues ), then this map will return an error in case the issue does not have links. You have to ensure in your final expression that this error will be handled. This can be done by using the field code only when there are issue links, e.g. issue.links != null && issue?.links?.map(link => link.linkedIssue.key).


All custom fields are available and can be referenced by one of the following:

  • ID: issue.customfield_10010 for default custom field types
  • key: issue['com.my.app.field-key'] for custom field types provided by 3rd party apps

Custom fields are returned as JSON values, using exactly the same format as in the issue REST API. You have to access the respective property, e.g. issue.customfield_10010.value.

Any field that is hidden in the active field configuration for the current issue will be returned as null, regardless of its actual value. Read more about hiding and showing fields in the documentation on the Changing a field configuration page.

All available field codes in one place!


Attachment


Comment


Component


Date and time

Issue-related


Jira software

If Jira Software is licensed for the current user, the following fields will also be available.

Epics (issues that have issue.isEpic equal to true or returned by issue.epic ) have additional, epic-specific fields. These fields are null for regular issues.

Numbers

Priority

Project

Resolution

Security

Status

System

User

Version


Action related


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