This blog post introduces ways to configure the default project workflow in Jira, so it accurately reflects the actual way of working in the project and the underlying processes.
Key fundamentals:
- A workflow in Jira defines the steps and statuses that an issue can go through during its lifecycle within the project and specifies their flow. Ideally, this workflow exactly reflects the actual work process in the project.
- Depending on preference, an overall workflow is used within a project or separate workflows are set up for individual or all issue types.
- A specific workflow designed for the respective workflows is created by copying the standard workflow provided by the system and adjusting it as required.
Every workflow consists of two core elements:
- Status: This represents the status of an issue at a certain point in the workflow. An issue can only be in one status at a specific point in time.
- Transition: A transition is a connection between two statuses that allows an issue to move from one status to another. A transition is a unilateral connection -i.e., if an issue needs to move between two statuses, two transitions must be created.
Quick-action screws for advanced workflow configuration:
With the help of the following setting options, each individual status transition in a workflow can be controlled even more precisely:
- Properties
- Triggers
- Conditions
- Validators
- Post Functions
To find out what needs to be used and how to fulfil the objectives, here is a summary of the most important properties and examples of use:
Properties
Objective: Changes of key-value pairs at transition or status.
What can I set: Properties can be used to change certain issue properties depending on transition or status achievement. The number of selectable options for the resolution field in the transition screen, for example, can be limited. Furthermore, the order of the transition button can be adjusted or the edit button for an issue can be completely removed as soon as it has reached a certain status (jira.issue.editable = false).
When should I set it: When certain issue properties like permissions, editability or order of the elements should change in relation to a transition or status.
Triggers
Objective: Automatic transition
What can I set: Triggers can be configurated in Jira workflows to respond to events in associated developer tools and automatically trigger a transition based on them.
For example, the transition from the status “To Do” can be triggered by “Branch created (Bitbucket Server)”. As soon as the event occurs, the transition is executed automatically
When should I set it: If the developers work with tools such as Bitbucket and GitHub that are linked to Jira. If configured correctly, an issue no longer needs to be manually moved to the status “In Progress” or “Code Review”, for example, but this is transitioned automatically by the system in real time.
Conditions
Objective: Restrict whether a transition is displayed
What can I set: Conditions can be used to define preconditions that must be fulfilled for a transition to be displayed to the user as a possible course of action.
For instance, you can restrict which users in the project should be able to see a certain transition (e.g., only assignees or reporters). Another restriction would be that a certain issue field must correspond to a predefined value for the transition to become visible as an option for a ticket.
! Several conditions can also be linked and grouped together until the desired logic is achieved!
When should I set it: If there are transitions in the workflow that should only be executed under certain circumstances, such as the user’s role or when certain values are reached.
Validators
Objective: To check whether the transition is executed.
What can I set: Validators can be used to check input values for validity. If the check is not successful, the transition is not executed. For example, it can be checked whether all mandatory fields have been filled in, the values are valid or whether the respective user has a certain entitlement.
This check also includes fields that were filled in in the corresponding transition screen.
! Without any other Jira add-on or plug-ins, only the “Permission Validator” and the “User Permission Validator” are available by default!
When should I set it: When a transition screen is used for the transition and the inputs made need to be reviewed for validity.
Post Functions
Objective: Automatic action after transition
What can I set: Post Functions can be used to set what should happen after a transition has been completed successfully. For example, updating a specific field, adding a comment, or sending e-mail notifications.
Note that each Jira Transition already has five basic Post Functions that cannot be edited, reordered, or deleted.
When should I set it: When an action is to be performed after a transition that is not covered by the five functions already available by default.
Further links for everyone who is still inquisitive:
- https://confluence.atlassian.com/jiracorecloud/how-do-i-build-the-workflow-i-want-765593066.html
- https://confluence.atlassian.com/adminjiracloud/editing-an-issue-workflow-844500771.html
- https://confluence.atlassian.com/adminjiracloud/advanced-workflow-configuration-776636620.html
- https://confluence.atlassian.com/adminjiraserver072/working-with-workflows-828787890.html