Work Item Selector for Jira Cloud
Allow users to select work items based on Jira Query Language (JQL).
A single- or multi-select field that offers only the work items a JQL query returns, and the JQL can take dynamic values from the user editing the field and from the work item the field sits on. It supports advanced search, automation, workflow validation and native work item linking, all of it with a native Atlassian look and feel.
Atlassian reviews this documentation before the listing goes live, so there is nothing to install yet. Everything on this page and in the documentation is final.
Native work item linking needs a link type, and it offers every work item the user can see.
Jira’s own work item link is instance-wide. An editor searching from a service desk ticket is offered every work item they can read, across every project on the site. On an enterprise instance that is tens of thousands of them, so the field they were given to record one relationship becomes a search problem.
The only option so far was to use that link and hope it worked. What was missing is a field whose search scope is a property of the field rather than of the instance.
Four things it does that the built-in linking does not.
Each one is set where it belongs in Jira, on the field context or on the workflow, so two fields on the same screen can behave differently without anyone negotiating a global setting.
Set the search scope in JQL
A Jira administrator sets the JQL on each field context, and that JQL can take dynamic values from the user editing the field and from the work item the field sits on.
Show the columns that make the choice obvious
One to seven columns on the selected work item cards: work type, key, summary, priority, status, assignee and custom fields. Enough for an editor to tell two similar work items apart without opening either.
Readable and writable from the rest of Jira
Automation actions set the field, and the application adds JQL functions so the field can be filtered, boarded and reported on across projects like any other Jira data.
Require the field before a transition
A workflow validator holds a transition until the selection satisfies the rules you set: a selection exists, the selected work items are in allowed statuses, they belong to allowed projects, and the selection creates no circular dependency back to the work item. The administrator writes the message a blocked person sees.
Every step is in the product you already administer.
No server component, nothing to host, and no support ticket to change how it behaves afterwards.
- 1Install from the Marketplace
One install, and the setup screens are the Atlassian ones you already use. There is no server to deploy and nothing to host, because the application runs on Forge inside your Atlassian Cloud site.
- 2Create the field
A Jira administrator creates the field from one of two types, Work Item Selector (Single Select) or Work Item Selector (Multi Select).
- 3Set the scope on the field context
Which JQL the field searches, which columns appear on the selected work items, and whether the field respects each user’s permissions. All of it in Jira’s own settings.
- 4Add the field to a screen
Settings, then Work items, then the screen schemes the work types use, exactly as with any other Jira custom field.
Host platform and compatibility.
Nothing leaves your Atlassian instance.
The application runs inside your Atlassian Cloud instance, and the values it stores stay there. No third party can read them, and neither can we.
- Egress
- None. No external permissions declared
- Storage
- Atlassian storage, inside your instance
- Oktul infrastructure
- None in the data path
- Sub-processors
- None
- Analytics or telemetry
- None collected
Atlassian grants this badge per application, to apps that store data only inside Atlassian and declare no external permissions.
What the programme requires (opens in a new tab)
This application is listed in the Cloud Security Alliance STAR Registry at Level 1, which is a self-assessment. We completed the CAIQ Lite questionnaire, all 138 questions, and published it for anyone to read.
Read the assessment on the STAR Registry (opens in a new tab)What runs before this application ships.
Suite sizes vary with what an application does, so these figures are about this application and no other.
- Automated tests
- 843
- Run on every release, including injection and security suites.
- Test suites
- 36
- Behaviour, configuration, permissions and input handling.
- Work items per field
- 100
- The ceiling is Atlassian Forge’s, not ours.
The limitations, next to the features they bound.
If any of these matter to your configuration, they are better found here than after you install.
How many work items can one field hold?
Does it run on Data Center or Server?
Why does the picker dropdown show plain text rather than icons?
Is the JQL scope a permission boundary?
Billed through the Atlassian Marketplace.
Pricing, the free trial and billing all run on the Marketplace listing, on the same terms as every other app in your instance. It lands on your existing Atlassian invoice, so there is no new supplier to onboard, no purchase order and no vendor security review of our payment handling.