Jira workflow configuration tips for project managers

This blog post presents ways in which the standard project workflow in Jira can be configured so that it accurately reflects the actual working methods in the project and the underlying processes.

The most important basics:

  • A workflow in Jira defines the steps and statuses that an issue can go through during its lifecycle within the project and determines their sequence. At best, this process 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 tailored to the respective project is created by copying the standard workflow provided by the system and adapting it accordingly.

Every workflow consists of two core elements:

  • Status: This represents the status of an issue at a specific point in the workflow. An issue can only be in one status at any given time:
  • Transition: A transition is a connection between two statuses that enables an issue to move from one status to another. A transition is a one-way connection – i.e. if an issue is to be moved back and forth between two statuses, two transitions must be created.

Adjusting screws for the extended workflow configuration:

The following setting options can be used to control each individual status transition in a workflow even more precisely:

  • Properties
  • Triggers
  • Conditions
  • Validators
  • Post
  • Functions

In order to find out what needs to be used to achieve the objective and how, here is a brief summary of the most important properties and examples of use:


Goal: Changes to key-value pairs during transition or status

What can I set? The properties can be used to change certain issue properties depending on transition or status achievement. For example, the number of selectable options for the resolution field on the transition screen can be restricted. In addition, the order of the transition buttons 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).

What should I set? If certain issue properties such as authorizations, editability or arrangement of elements in relation to a transition or status are to change.


Goal: Automatic transition

What can I set? Triggers can be configured in Jira workflows so that they react to events in linked developer tools and automatically trigger a transition based on this.

For example, the trigger “Branch created (Bitbucket Server)” can be selected for the transition from the status “To Do” to “In Progress”. As soon as the event occurs, the transition is executed automatically.

What should I set? If the developers work with tools such as BitBucket and GitHub and these are linked to Jira. If configured correctly, an issue no longer needs to be manually moved to the “In Progress” or “Code Review” status, for example, but is automatically handled by the system in real time.


Goal: Restrict whether transition is dispayed

What can I set? Conditions can be used to define preconditions that must be fulfilled for a transition to be displayed as a possible action option for the user.

For example, you can restrict for which users in the project a certain transition should be visible and therefore possible (e.g. only for assignees or reporters). Another restriction would be that a certain issue field must correspond to a predefined value for the transition to be visible as an option for a ticket.

! Several conditions can also be linked and grouped together until the desired logic is achieved. !

What should I set? If there are transitions in the workflow that should only be executed under specific conditions, such as the user’s role or when certain values are reached.


Goal: Check whether transition is being carried out

What can I set? Validators can be used to check the validity of input values. If the check fails, the transition is not carried out. For example, you can check whether all mandatory fields have been filled in, whether the values are valid or whether the respective user has a certain authorization.

The check also takes into account fields that have been filled in on the associated transition screen.

! Without additional Jira add-ons or plugins, only the “Permission Validator” and the “User Permission Validator” are available by default. !

What should I set? If a transition screen is used for the transition and the entries made must be checked for validity.

Post Functions

Goal: Automatic action after transition

What can I set? Post Functions can be used to set what should happen after a transition has been successfully completed. For example, updating a specific field, adding a comment or sending email notifications.


Please note that each Jira transition already has 5 basic post functions that cannot be changed, reordered or deleted.

What should I set? If an action is to be carried out after a transition that is not covered by the 5 functions already available by default.

More blog posts