• Products
  • Get started
  • 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 a request.

  2. Validate details, which happens when someone tries to transition a request.

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

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 a request unless its criteria is met. Unlike the Validate details rule type, this type doesn’t give people to correct a request 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 request

Some service teams have a manager or team lead who triages and distributes incoming requests to the most appropriate agent. They might want to verify the requests are valid or link them to other known requests in their project before assigning someone to work on them.

In this case, you can use a rule to prevent requests from moving down the workflow before managers or team leads have properly triaged the request. To do so:

  1. Create a “Triaging” status in your workflow.

  2. Change the starting status to move requests into the “Triaging” status.

  3. Create an outgoing transition to the rest of the request’s workflow called “Send to team”.

  4. Add a Restrict who can move a request rule to this new transition to restrict it to the manager or team lead.

Jira Service Management prevents any other person in the project from moving newly-created requests forward.

Validate details

This rule type makes sure details are correct when transitioning an request, and stops the transition if they aren’t. When there are incorrect details, the person transitioning the request 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 request if the details aren’t met. That’s why Validate details rules happen when someone is transitioning an request: 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 request to add information to the request.

Perform actions

This rule type automatically does something after transitioning the request. 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 a request can be transitioned. They’re simply here to help you get work done faster.

Example: Assign a request

Certain members of your service team may be subject matter experts in particular areas of service, or have explicit responsibility in carrying out certain requests. For example, you may have a service agent who's responsible for providing access to software tools or messaging lists. And, you might have a senior service agent who’s responsible for assessing how to escalate difficult or high-impact requests.

You can set up your request workflows to automatically assign certain request types to the person who’s responsibility covers that type of request.

In the example above, you might:

  • Navigate to the request type settings for IT help and edit its workflow. Select the first transition in the workflow (the Create issue transition from Start to Waiting for support). Add the Assign a request to someone rule to automatically assign these requests to your access specialist. Now, when an IT help request is created, your IT help specialist will be assigned the ticket automatically, skipping the need to triage your requests manually. Repeat this for each type of request, assigning them to the correct subject matter expert on your service team, and you’ll never have to triage requests again.

  • Edit your workflow to change the assignee when requests are moved into the Escalated status. You can set a rule to automatically assign these requests to a senior service agent or manager and they’ll be notified of particularly difficult or high-impact requests. Service agents can continue to w

Additional Help