When it comes to Jira and Jira Service Management (JSM), workflows are among the most powerful features. They allow you to guide issues through a lifecycle that matches your team’s processes. But beyond the basics of statuses and transitions lies a lesser-known gem: workflow properties.
Properties can fine-tune how transitions behave, controlling what users see or select at each step. With a little configuration, you can enforce business rules, simplify choices, and improve data consistency. Let’s explore how.
Why Workflow Properties Matter
Think of properties as guardrails for your workflows. Instead of presenting every possible option to users, you can narrow the list to what makes sense in the current context. This reduces errors, speeds up work, and ensures that your data remains clean and meaningful.
Here are three common use cases where workflow properties shine.
1. Resolution Control
When issues move to a “done” status—such as Canceled, Closed, or Resolved—it’s important that the Resolution field is set. There are two common approaches:
- 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 select Fixed in this context would be poor practice. The solution? Use properties to restrict the available resolution choices to only those relevant for the transition. Custom Select List
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 should 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
We fix this by limiting 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.
Here, we solve the issues by restricting available resolution choices per transition, ensuring consistency with business rules.
How to Configure Workflow Properties
So, how do we make this work? Start by navigating to the Properties section of the transition you want to configure, and add a new property.
- Locate the “Properties” section for the selected transition.
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:
- field.resolution.include: Use this to specify which resolution IDs should be available in the select list.
- 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: field.resolution.include
- Value: 10000,10007
Tip: You can find resolution IDs by navigating to Administration > Issues > Resolutions, editing a resolution, and grabbing the ID from the URL.
Our Key Takeaways
Workflow properties give you more control over Jira transitions. By tailoring field options to match the context, you are empowered to reduce errors, keep workflows aligned with organizational rules, and improve the user experience.
Workflow properties are just one example of how Jira can be customized to support better governance, smarter automation, and more efficient teams. When configured with intention, these capabilities can transform how work flows across your organization.
If you’re ready to refine your Jira environment or need expert guidance in designing workflows that truly fit your business, the team at Forty8Fifty Labs is here to help. Connect with us today to explore how we can optimize your Jira and JSM setup.
