Field Behaviour Examples (In-app)
Browse in-app field behaviour scripts that set default values, rename fields, hide screen tabs, and read view type, space, and work item context.
The following examples are available in-app via the Example scripts modal when you're configuring field behaviours. Insert any example into your script and customise it, then configure the field behaviour to apply to the spaces, work item types, and views you want.
Set the default value for the summary field
Set the summary field to a default value when the work item is opened or created.
Why it's useful: Provides a starting point for users, encourages consistent naming patterns, and reduces the chance of empty or unclear summaries.
Set the description field using markdown
Populate the description field with markdown content, which is automatically converted to Atlassian Document Format (ADF).
Why it's useful: Lets you define reusable templates (for example, acceptance criteria or checklists) so descriptions are structured and complete without users having to retype standard content.
Change a field's display name
Override the display name of a field (for example, rename the priority field).
Why it's useful: Allows you to use terminology that matches your team's language or business domain while still relying on the same underlying field and data.
List screen tabs
Read the screen tabs available on the current screen with getScreenTabs() and log each tab's id, position, and visibility.
Why it's useful: Helps you inspect the current screen configuration and serves as a starting point when you want to build more advanced tab-related behaviours.
When you call getScreenTabs(), it returns an array of tabs in the same order they appear on the screen. This means you can work with tabs by their position instead of looking up their id. For example, to access the second tab:
const tabs = api.getScreenTabs?.() ?? []
const secondTab = tabs[1]
secondTab?.setVisible(false)This can be easier than finding and maintaining explicit tab ids, especially if you only need to show or hide tabs based on their position.
Hide a screen tab
Hide a tab on the work item screen by targeting its position.
Why it's useful: Lets you simplify screens for specific contexts or user groups by hiding tabs that are not relevant, reducing clutter and potential confusion.
Access the view type from context
Read context.viewType to find out which screen your behaviour is running on.
Why it's useful: Lets a single behaviour do different things on different screens, and lets you exit early on screens where it should not run at all.
The value of context.viewType tells you where the behaviour is running:
GICis the work item create dialog.IssueViewis viewing or editing a work item.IssueTransitionis a transition screen.JSMRequestCreateis the Jira Service Management customer portal request form.GICAgentView,IssueViewAgentViewandIssueTransitionAgentVieware the equivalent screens on a Jira Service Management service desk space.
Access the space from context
Read context.project to access the key, id, and type of the space the work item belongs to.
Why it's useful: Lets you apply one behaviour across several spaces while only acting on some of them, instead of creating and maintaining a separate behaviour for each space.
Access the work item type from context
Read context.issueType to access the name and id of the work item type being created or edited.
Why it's useful: Lets you vary a behaviour by work item type, for example making a field required on bugs but leaving it optional on tasks.
Access the work item key from context
Read context.issue to access the key and id of the work item being edited. This is only available on the work item view and transition screens, not on the create dialog, because the work item does not exist yet.
Why it's useful: Lets you show details about the work item being edited, or look up related data using its key. Check the view type first, so the behaviour exits cleanly on screens where context.issue is not available.