JSM Tips & Tricks - Customizing Select-Lists on a Transition

[#1]

Hi all,

Welcome to the next installment in my JSM Tips & Tricks series.

Within Jira and JSM, one of the most powerful features is workflow functionality. A lesser-known but highly valuable capability within workflows is the use of Properties.

👉 Did you know you can use properties to control the options a user sees during a workflow transition by setting property values?

---

Use Cases:

1. Resolution Control

When transitioning an issue to a “done” status (e.g., Canceled, Closed, Resolved), it’s essential that a Resolution be set. This can be done in two common ways:

• Post Function: Hard-code a resolution (e.g., automatically set Canceled when transitioning to Canceled).

• Transition Screen: Add the Resolution field so the user must select a value.

Both approaches are useful, but they also have limitations. For example, showing the full list of resolutions isn’t always appropriate. If an issue is moving to a status like Rejected, you may want only Cannot Reproduce, Out of Scope, or Not a Bug available—allowing a user to only select Won't Do in this context would be poor practice.

✅ Solution: Use properties to restrict the available resolution choices to only those relevant for the transition.

---

2. Custom Select Lists

another example is managing select-list field values during transitions. Imagine a field called Functional Area with options such as:
User Interface, Application Layer, API, Database, Backend, Business Logic, Integration Layer, Server-Side Processing.

We could have a workflow such as the following:

If you have transitions like Send to Front End or Send to Back End, the values could be context-sensitive:

• Send to Front End → User Interface, Application Layer, API, Business Logic, Integration Layer

• Send to Back End → API, Database, Backend, Business Logic, Integration Layer, Server-Side Processing

✅ Solution: Limit field choices based on the transition, ensuring users only select valid options.

---

3. Multiple Transitions to the Same Status

It’s also common to have multiple transitions lead to the same status (e.g., Canceled). Depending on the path taken, you may want to enforce different resolution options.

Example: From Review → Canceled, policy may dictate that the only valid resolution is Not a Bug, while moving from Front End Development, may want a choice of reasons to cancel it.  (E.G. Not in scope, Bad ROI, Not a Bug, Working as Designed, etc.)

✅ Solution: Restrict available resolution choices per transition, ensuring consistency with business rules.

---

The Method

So, how do we make this work? Simple—go to the Properties section of the transition you want to configure, and add a new property.

• Locate the "Properties" section for the selected transition.

• Add a new property key:

  • jira.field.resolution.include: Use this to specify which resolution IDs should be available in the select list.

  • jira.field.resolution.exclude: Use this to specify which resolution IDs should not be available in the select list.

• Add a new property value:
  Enter a comma-separated list of the resolution IDs you want to include or exclude.

Example:

To limit the "Resolution" field to only show "Fixed" (ID: 10000) and "Completed" (ID: 10007) when transitioning an issue to "Done," you would add the following property to the "Done" transition:

• Key: jira.field.resolution.include

• Value: 10000,10007

👉 You can find the resolution IDs by navigating to Jira's "Resolutions" section in the administration settings, editing a resolution, and extracting the ID from the URL.

---

🔑 Key Takeaway: Workflow properties in Jira allow you to refine field options during transitions, making workflows more intuitive, compliant, and aligned with organizational processes.

Have fun and feel free let me know if you want assistance with anything Jira!

…Robert Nadon

[Susan Waldrip]

Really enjoying your JSM Tips & Tricks series, @Robert Nadon ! Thanks for taking the time to share your insights, very helpful for newer JSM Admins like myself.