On this page
Field Configuration
Before starting the field configuration, please follow the instructions for creating custom fields: Create a Custom Field
Step 1: Set a name and description
Provide a good name for the new custom field. Make it descriptive, concise, and easy to understand for others who will use it. Avoid using ambiguous or overly technical terms.
Step 2: Add options
This field allows you to create as many levels as needed to cover your requirements. You can also define display options or if all levels have to be selected to prevent empty fields.
Step 3 (Optional): Add custom field labels
In conjunction with the select options, you can further enhance customization by adding custom labels for each option level. To do so, enable the "enable field label per parent" option and click "Edit field level" for the specific option level you wish to customize.
Step 4 (Optional): Customize display and required status
Regarding the display option, you have the flexibility to choose between showcasing the entire path or just the final option. For example a full path may look like this: Option 1 -> Option 1.1 -> Option 1.1.1 , whereas last step like this: Option 1.1.1.
If you want the cascading select to be completely selected, check the required selection toggle. This important if you want the field to be required.
Step 5 (Optional): Restrict visibility
By restricting the visibility of the options, only selected users can view the potential values in the issue view. Please note that they can still see the selected value, but are unable to change it.
You can choose to restrict visibility by roles, individual users, or groups.
Enabling this setting will switch the saving location to 'storage,' making it incompatible with JSM.
If a user is not permitted to see the options, the edit screen will appear as shown. Please be aware that the selected value will still be visible.
Please note that administrators are always able to see the options.
A note to additional storage
In the case of extensive configurations with a multitude of options or levels (exceeding 500), you might encounter the maximum storage capacity for the field configuration. In such instances, a warning will prompt you to consider upgrading to a larger storage capacity to accommodate additional options.
Please be aware that modifying this storage option will result in the complete deactivation of the cascading select functionality in Jira Service Management, impacting both the request form and portal view. This is due to technical limitations.
Field view and edit
Related Use Cases
More use cases are coming soon. In the meantime, check out our other use cases.
Jira Service Management (JSM)
Before you can add a custom field for Jira Service Management (JSM) projects, you first need to setup the custom field: https://help-seibertmedia.atlassian.net/wiki/spaces/ACF/pages/12288051/Cascading+Select#Field-Configuration. Then follow the guide to use the field in the request form or the portal view: Add Custom Fields to Jira Service Management
JQL expression
The Cascading Select is not compatible with JQL queries.
Data Structure (Automation)
To set the value via automation, you need the following object structure
{
"selection": [
{
"id": number,
"name": string,
"children": number[]
}
]
}
We know that this is kind of complex (depending on the number of levels). So here’s an example of the configuration used in the screenshots above.
{
"selection": [
{
"id": "0",
"name": "Option 1",
"children": [
"2" <-- the id of Option 1.1
]
},
{
"id": "2",
"name": "Option 1.1",
"children": [
"3" <-- the id of Option 1.1.1
]
},
{
"id": "3",
"name": "Option 1.1.1",
"children": []
}
]
}
Tip: To get the actual values, we recommend to print out the desired value first. this can be done via an automation rule that writes the value into a simple text field.