• Products
  • Documentation
  • Resources

Jira Automation docs have moved

All content related to Jira Cloud Automation, previously under the Automate your Jira processes and workflows section, have moved to the new Cloud Automation docs.

Go to Cloud Automation documentation | Why did we do this?

What are the different workflow rule types?

This page describes each of the workflow rule types you can use, and gives an example of why you might use them. Learn more about workflow rules.

The three types of workflow rules happen in this order:

  1. Restrict transition, which happens before someone tries to transition an issue.

  2. Validate details, which happens when someone tries to transition an issue.

  3. Perform actions, which happens after someone transitions the issue.

Restrict transition

This rule type hides the transition from certain people, or from everyone when certain conditions aren’t met. If you add one of these to a transition, people won’t see the transition on an issue unless its criteria is met. Unlike the Validate details rule type, this type doesn’t give people to correct an issue and transition again (they won’t even see the transition). This is very useful for security, but not useful if you just want to remind someone to do something before transitioning.

Most Restrict transition rules start with ‘Restrict’.

Example: Restrict who can move an issue

Multi-discipline teams usually have different people working on a task at different stages in their process. For example, a small feature team may have these steps in their process:

To do → In design → In development → In review → Done

The disciplines in the team may be mapped to roles:

  • Designer.

  • Software engineer.

  • Quality assurance.

Learn more about managing project roles.

Using the rule, they can add these restrictions to make sure the right roles move their issues:

  • For issues moving from In design, restrict who can move the issue to the role Designer.

  • For issues moving from In development, restrict who can move the issue to the role Software engineer.

  • For issues moving from In review, restrict who can move the issue to the role Quality assurance.

Validate details

This rule type makes sure details are correct when transitioning an issue, and stops the transition if they aren’t. When there are incorrect details, the person transitioning the issue will be prompted to fix them.

There’s a subtle difference between this type and Restrict transition. Whereas Restrict transition will hide the transition if they aren’t met, Validate details won’t ever hide the transition. People will be able to see and select the transition, but won’t be able to finish moving the issue if the details aren’t met. That’s why Validate details rules happen when someone is transitioning an issue: it’s after the transition is selected, and before the transition happens.

Most Validate details rules start with ‘Validate’. The exceptions are:

  • Show a screen (in company-managed projects)

  • Remind people to update fields (in team-managed projects)

Which happen before the other Validate details rules, and allow whoever is transitioning the issue to add information to the issue.

Perform actions

This rule type automatically does something after transitioning the issue. They’re useful in saving time doing tasks you’d have to do manually. Unlike Restrict transition and Validate details rules which enforce conditions for a transition to pass, Perform actions rules don’t narrow who or when an issue can be transitioned. They’re simply here to help you get work done faster.

Example: Assign an issue

Multi-discipline teams usually hand off tasks at different stages in their process. For example, a small feature team may have these columns on their board:

To do → In design → In development → In review → Done

You can create rules to assign issues to each discipline across the board:

  • For issues moving to In design, assign to the team's designer. They then provide implementation details, specifications, and requirements.

  • For issues moving to In development, assign to the team's feature lead. They then write the code or delegate to other developers in the team.

  • For issues moving to In review, assign to the team's quality assurance champion. They then provide testing notes or build automated quality tests.

  • For issues moving to Done, unassign the issue.

Additional Help