Moving from Issue Picker for Jira
Moving from Issue Picker for Jira to Work Item Selector: add the new field beside the old one and copy the selections with one Automation rule.
Add a Work Item Selector field beside your Issue Picker field, copy the selections with one Automation rule, then retire the old field. Both fields work side by side while you move, and nobody loses a selection on the day you switch.
What you get that Issue Picker does not have
From the comparison, checked on 24.09.2026 against Issue Picker for Jira (opens in a new tab) by codecentric AG:
- An Automation action of its own. You set the field with a form, not with JSON in Jira’s Edit work item action. Automation and JQL
- Workflow validation. A transition waits until the selected work items meet your conditions. Workflow validation
- JQL functions and reverse lookups. Find what a work item selects and what selects it, in JQL, smart values and the REST API. Automation and JQL
- Any field on the card. You choose which fields each selected work item shows, not a fixed set. Set up the field
- Synced Jira links. Removing the link removes the selection too. Set up the field
- Atlassian’s own design on the create screen and the customer portal.
Both apps run on Atlassian and both offer permission modes.
Move in six steps
- Install Work Item Selector
From the Marketplace, as in Install the app. Issue Picker stays installed until the last step.
- Create the new field
Single select or multi select, matching the old field. Give it a JQL scope that offers at least the work items the old field offered.
- Put it on the same screens
Add it to the screens, field schemes and request types that hold the old field, as in Set up the field.
- Copy the selections
One scheduled Automation rule, set out below. Run it once, check the result, and run it again until it finds nothing left.
- Point filters, boards and rules at the new field
Replace the old field in JQL filters, board quick filters, dashboards and Automation rules. The JQL functions can replace searches the old field could not make.
- Retire the old field
Remove it from its screens once nothing reads it, then uninstall Issue Picker.
The rule that copies the selections
Create a rule in Jira Automation, at the scope of the spaces that hold the old field:
| Part | Setting |
|---|---|
| Trigger | Scheduled, running a JQL search for the work items to act on: "Old field" is not EMPTY AND "New field" is EMPTY |
| Action | Set work item selection: the new field, Replace, and in Work items the old field’s smart value, for example {{issue.customfield_10050}} |
The "New field" is EMPTY condition lets a run pick up where the last one stopped. On a large
site, run the rule as often as it needs. Use the field names your site shows, and the
old field’s id from Custom fields in Jira settings.
The action reads work item keys separated by commas, spaces or new lines. Before you copy
anything, add a Log action with the old field’s smart value and run the rule on one work
item. If the audit log shows keys such as OPS-12, OPS-15, the copy works as set out above.
If it shows anything else, such as summaries or ids, ask us in the
Help Center (opens in a new tab) and we help you write
the smart value.
A key outside the new field’s JQL scope is skipped and named in the audit log. A single select field takes one key and a multi select field up to 100.
Common questions
- Can both fields run at the same time?
- Yes. They are separate custom fields. The old one keeps working until you remove it from its screens.
- Do I have to copy every selection by hand?
- No. One scheduled Automation rule copies them with the Set work item selection action.
- What happens to a selected work item outside the new JQL scope?
- The action skips it and names it in the rule's audit log. Widen the scope, or leave it out on purpose.
Related
A problem or a question? Write to support@oktul.com or open a request in the Help Center (opens in a new tab).