Supported Fields and Products for Field Behaviours

See which Jira products, views, and fields work with field behaviours, and which methods each field supports on Create, View, and Transition screens.

Field behaviours let you modify Jira fields dynamically based on logic you define in a script. You can change a field's visibility, value, label, or whether it is required. They run on top of Atlassian's Forge UI Modifications API, which means support depends on what Atlassian exposes through that API. Not every field or method is available in every view. This page outlines which Jira products, views, and fields are supported, and what you can do with each field.

Supported Jira products

Field behaviours are supported across Jira and Jira Service Management. In Jira Service Management, what is supported depends on which screens you target:

Work item screens support Create, Transition and View/Edit. Target them by selecting a service desk space after selecting work item screens.
The customer portal supports the Create request view only.


Jira product	Supported capability	Supported
Jira	Company-managed spaces
Jira	Team-managed spaces
Jira Service Management	Work item screens: Create, Transition and View/Edit
Jira Service Management	Customer portal: Create request only

Supported views

Field behaviours can be configured to run in three different views on work item screens. Each view has its own set of supported fields and methods, so it is worth checking the relevant table below before writing your script.


View	Space type
Create view	Company-managed, Team-managed, Service desk
Work item view	Company-managed, Team-managed, Service desk
Transition view	Company-managed, Service desk

Note: The customer portal is configured separately and supports the Create request view only, so it does not appear in this table.

Note: Why isn't my transition view behaviour running?

Field behaviours mapped to the transition view only run if your Jira instance has Atlassian's new issue transition experience enabled. On some instances this is not enabled, and where it is not, the field behaviour is saved and valid but does not run, and no error is shown. So if a transition view behaviour appears to do nothing, first check whether this experience is enabled on your instance. If it is not enabled, raise a support ticket with Atlassian asking them to turn on the new issue transition experience for your site.

Note: Refer to Atlassian's Jira UI modifications documentation for more details.

Supported fields

Fields are accessed in your script using getFieldById('fieldId'), where fieldId is the Jira field identifier (for example, summary, priority, or a custom field ID).

System fields and custom fields

Some Jira-native system fields can share a type with custom fields. For example, the Labels field is a Jira-native system field. Only Jira-native system fields are supported, so your field behaviours may not work correctly if you have created a custom field of the same type. System field types are identified in each of the supported fields tables below, while custom field types are marked with (error) .

Understanding behaviour contexts

Every field behaviour is registered against a set of contexts. A context is a unique combination of a space, a work type, and a view type. On a service desk space, the request type is also part of the context. Atlassian's Forge UI Modifications API has a limit on the number of contexts an app can register, so it is important to understand how your configuration affects the total count.

Using All spaces keeps the space dimension at a single context, regardless of how many spaces exist in your instance. However, each additional work type and view type you select multiplies that count, and All spaces also doubles the total. For example:


Field	Selected	Contexts
Space	All spaces (100 spaces)	1
Work types	Story, Bug, Task	3
Jira views	Work item Create, Work item View	2
Screen types	Work item screens and service desk agent screens	2
Total		12

The Screen types row applies because All spaces was used. ScriptRunner cannot tell in advance which of those spaces are service desks, so it registers each work type and view combination twice: once for ordinary work item screens and once for service desk agent screens. Selecting spaces individually avoids this.

Note that All spaces and All work types cannot be selected at the same time. For more details on context limits, see field behaviour limitations.

Create view supported fields

The Create view is triggered when a user opens the global work item create dialog. The following fields and methods are supported.


Field/methods	SystemField Type	setName getName	setDescription getDescription	setVisible isVisible	setValue getValue	setReadOnly isReadOnly	setRequired isRequired	setOptionsVisibility getOptionsVisibility
affects version
assignee
cascading select
components
checkboxes
date picker
date time picker
description
due date
fix versions
issue type
labels
multi select
multi user picker
number
paragraph
parent
people
priority
project picker
radio buttons
reporter
single select
summary
target start
target end
text field
url
user picker

Note: When using setValue on description or paragraph fields, markdown is automatically converted to Atlassian Document Format (ADF).

Work item view supported fields

The work item view is triggered when a user opens or edits an existing work item. Field behaviours configured for this view run across all the supported work item views listed in the next section.

Note: Hidden fields

On the work item view, fields with no value are automatically hidden when set to read-only. For example, empty read-only date picker, text, select list, checkbox, radio, and number fields are hidden by default when the user does not have permission to edit the work item.


Field/methods	SystemField Type	setName getName	setDescription getDescription	setVisible isVisible	setValue getValue	setReadOnly isReadOnly	setRequired isRequired	setOptionsVisibility getOptionsVisibility
affects versions
assignee
cascading select
components
checkboxes
date picker
date time picker
description
fix versions
labels
multi select
multi user picker
number
original estimate
paragraph
parent
people
priority
project picker
radio buttons
reporter
single select
status
summary
text field
url
user picker

Note: When using setValue on description or paragraph fields, markdown is automatically converted to Atlassian Document Format (ADF).

Supported views for work item view

Field behaviours configured for the work item view are triggered when the work item is accessed through any of the following views:

Full page work item
Board work item
Backlog work item
List work item
Work items view
Search work item (global search)

Transition view supported fields

The Transition view is triggered when a user transitions a work item through a workflow. This view has the broadest method support of the three views.

Note: Transition dialog required

Field behaviours on the transition view run only in Atlassian's new work item transition dialog. If this has not been enabled for your instance, field behaviours on the transition view will not work.


Field/methods	SystemField Type	setName getName	setDescription getDescription	setVisible isVisible	setValue getValue	setReadOnly isReadOnly	setRequired isRequired	setOptionsVisibility getOptionsVisibility
affects version
assignee
cascading select
checkboxes
date picker
date time picker
description
fix versions
issue type
labels
multi select
multi user picker
number
original estimate
paragraph
parent
priority
project picker
radio buttons
reporter
resolution
single select
summary
text field
url
user picker

Note: When using setValue on description or paragraph fields, markdown is automatically converted to Atlassian Document Format (ADF).

Screen tabs

In addition to fields, field behaviours can interact with screen tabs. This lets you show or hide tabs dynamically based on your script logic. For example, you could hide a tab that is not relevant for a particular work type or user.

Screen tabs are accessed using api.getScreenTabs() or api.getScreenTabById(), and are only available on screens that have tabs configured. If no tabs are present, getScreenTabs() returns an empty array. For more details, see Atlassian's querying screen tabs documentation.


Method	Description
`api.getScreenTabs()`	Returns an array of all screen tabs in the order they appear on screen
`api.getScreenTabById('tabId')`	Returns a specific screen tab by its identifier, or `undefined` if no tab has that id

Each tab object supports the following methods:


Method	Description
`getId()`	Returns the tab's identifier
`isVisible()`	Returns whether the tab is currently visible
`setVisible(boolean)`	Shows or hides the tab. Returns the tab, so you can chain another method
`focus()`	Brings the tab to the front, as though the user had selected it. Returns the tab