Creating multiple Jira tickets automatically based on values selected in a custom multi-selection field, using Jira Automation.
Platform Notice: Cloud Only - This article only applies to Atlassian apps on the cloud platform.
Summary
Use Jira Automation to create separate follow-up work items from one source work item when a custom multi-select field contains more than one value.
This article assumes that the custom field already exists and that you configured its options. "Multi Customer Selection” is an example field name, not a built-in Jira Service Management field. Replace the example field name and field ID with the field used in your space.
Diagnosis
An agent updates an work item with values in the Multi Customer Selection field (e.g., Customer A, Customer B).
Based on the selected values, separate tickets need to be created automatically.
Cause
Jira does not natively support creating multiple tickets from values selected in a multi-select field. A workaround using Jira Automation is required to achieve this.
Solution
The article covers two solution patterns:
Fixed-value fan-out: Use this when the possible values are a small, known list such as Customer A, Customer B, and Customer C.
Dynamic-value fan-out: Use this when the number of selected values varies and the flow must process each selected value.
Choose the right method
Requirement | Use this method |
A small, fixed set of known values | Fixed-value conditions and create-work-item actions |
Any number of selected values | Advanced branching over a list of selected values |
Clone each work item, keep one value on each clone, and link clones to the original | Dynamic-value fan-out |
Before you begin
Confirm the following before building the Automation flow:
The source Space has a custom multi-select field with the required options.
The field name and field ID used in the smart values match the field in your Space.
You know whether the flow should run when the work item is created or when the field is later updated. Use one trigger consistently;
Decide whether the original work item keeps all selected values, keeps only the first value, or is left unchanged after the follow-up work items are created.
Method 1: Fixed-value fan-out
Use this method when the values are known in advance.
Add the appropriate trigger:
Work Item Created for a new work item, or
Work Item Updated when the flow should run after a field change.
Add an work type condition and a condition that the custom multi-select field contains a value.
Add one conditional branch per known value.
In each branch, use Create Work Item and set the custom field to that branch’s value.
Use
{{issue.key}}in the summary or description when the new work item should retain a reference to the source work item.Test each value independently, then test a selection containing multiple values.
Method 2: Dynamic fan-out for every selected value
Use this method when a customer can select an arbitrary number of values. The following example uses a multi-select field named Environment-QA with field ID customfield_10300. Replace that ID with the field ID from your own Space.
1. Trigger the Automation
Use Work Item Created when a new Task should be split into follow-up work items. If the Automation is intended to run after a later edit, use Work Item Updated instead and add a guard that prevents the same values from being processed repeatedly.
2. Build a list of values to process
If the original work item should retain the first selected value, create a variable that contains the remaining values:
{{#issue.customfield_10300}}{{^first}}{{value}}{{^last}}, {{/last}}{{/first}}{{/issue.customfield_10300}}
For this example, the variable is named environments.
3. Add an advanced branch
Add an Advanced branching component and use:
{{environments.split(",")}}
Name the branch variable currentEnv so it can be used by the actions inside the branch.
4. Clone and set the current value
Inside the branch:
Use Clone Work Item so each selected value produces a separate work item.
Set the custom multi-select field on the clone to the current branch value, for example
{{currentEnv}}.Use the exact option value expected by the field. Only normalize whitespace if the option values in that Space require it; do not remove meaningful spaces from legitimate option names.
Link the clone back to the original trigger work item.
5. Keep the first value on the original, if required
Outside the branch, update the original field to the first selected value:
{{issue.customfield_10300.get(0)}}
If the intended result is one clone for every selected value, rather than keeping the first value on the original, adjust the list and branching logic accordingly.
Verification example
Given:
Environment-QA = [cc1qa1, cc1qa2, cc1qa3]
The “keep the first value” variant should result in:
The original work item retaining
cc1qa1.One clone containing
cc1qa2.One clone containing
cc1qa3.Each clone linked to the original work item.
Verify the result with both two values and three values. Also verify that rerunning or updating the original does not create unintended duplicates.
Troubleshooting smart values
Do not use substring() or slice() as if the multi-select field were a plain string. A multi-select field is a list of option values. Use the list iteration and advanced-branching pattern above, and replace customfield_10300 with the actual field ID for the Space.
If the flow cannot find the field or cannot set a value, confirm that:
The field is available for the source work item type.
The field ID is correct.
The option text matches the configured option exactly.
The automation actor can create, clone, edit, and link the relevant work items.
Scope and limitations
This pattern is for Jira Automation flows operating on a custom multi-select field. It is not a built-in “multi-customer” feature. The same automation concepts may be used in Jira Cloud and Jira Service Management Cloud, but the available work-item types, fields, and menu labels depend on the product and Space configuration.
Was this helpful?