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).
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:
| Context | Description |
|---|---|
| The issue that is processed by the workflow post function |
| 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:
depending on your configuration. Read more about seeds. |
| Some data does not have an issue context (e.g. the currently logged in user or the system date and time) |
action | This 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 code | Output |
|---|---|
| The description of the current issue |
| The summary of the parent issue |
| 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" |
| 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}. (
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 tonull.
- 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
- 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.
- If a field has no value (
- 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
issueor it'sparent. 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 tonull, 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.
All available field codes in one place!
If you still have questions, feel free to refer to our support team.
