Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

How to create global looping transitions in a Jira workflow

Have you ever needed a button in an issue just to do stuff without modifying the issue status? And what about applying edit permissions on the field level? This article shows how to set workflows for covering both needs in a cost-effective way.

Natively, Jira workflows count with a really powerful feature which is just a little bit hidden. Let's name it global looping transition, which is the key functionality for achieving our goals, and has definitely changed the way I design workflows since I discovered it.

What is a global looping transition?

A global looping transition is a special kind of workflow transition that meets these two characteristics at once:

  • It is global, meaning that it can be used from any status in the workflow.
  • It loops, meaning that the status of origin is also the status of destination. In other words, the status of an issue does not change on using this kind of transition.

How does it look like?

This is the graphical representation of a global looping transition named Do something:


Nice! Isn't it?

How can I set that kind of transition?

A global looping transition can only be set through the diagram mode of the workflow editor, by following these steps:

  1. Click on the Add transition button:


  2. Select the following values in the dialog form:


  3. Give the transition a descriptive name and, finally, click on the Add button.

That's it! The transition will be created.

Some notes about global looping transitions...

  • You'll need to refresh the workflow editor page in your web browser before being able to add conditions, validators, post-functions or transition properties.
  • A workflow may contain multiple global looping transitions, all of which will be displayed in the same area.


  • (Edit note on 17/Dec/2021: This point now just applies to Data Center instances) Adding opsbar-sequence property to all workflow transitions is a good way for displaying transitions in the desired order. While that's true for any kind of transitions, it's especially relevant for global looping ones, as it's generally preferable to display first those transitions that lead to a status change for advancing the issue through its workflow.

Use case: Triggering a post-function

Sometimes you just need to add a button to the issue detail view in order to perform actions somehow related to said issue which do not require to apply a status change.

The inefficient multiple looping (not global) transitions approach

While that purpose may be covered by creating a transition from a status to itself and adding an appropriate post-function, a similar transition should be created in each status from which the functionality should be available.


This approach is not easy to maintain, as it requires setting multiple times the very same thing, both in its initial configuration and in future changes.

The inconsistent global (not looping) transition approach

An alternative yet bad approach consists of adding a post-function to a global transition targeting a status specifically created for this purpose. In example, if the post-function executes a calculation and modifies a field accordingly, a status named Calculating with a global transition could be created.


However, this is just a poor workaround, because:

  • Calculating is not a phase (status) in the issue's lifecycle (workflow), but a mere action that requires less than a second to complete. Furthermore, it can affect your reporting measures of time in status or even SLA compliance, unless additional configurations were set to prevent such things from happening.
  • Workflows with strict requirements which rely on issues following certain specific paths may force to set additional means for returning the issue to the previous status in order to preserve consistency. Applying those extra settings would unnecessarily increase complexity with no value in return. What is more, I've even witnessed a case where a post-function was set to transition automatically to the previous status and, on stumbling upon an error caused by a different post-function, an infinite transition loop was caused. Definitely not worth it!

The correct global looping transition approach

As you've probably already noticed, using a global looping transition with the appropriate post-function is the correct way to go here, as it doesn't have any of the disadvantages caused by its counterparties.


This is a simple and clean solution that complies with both the DRY and KISS principles (dry kiss?), strongly recommended in Jira configurations.

Use case: Edit permission on the field level

The ability to control who can edit a specific field in Jira is usually implemented this way:

  1. Remove the field from the edit issue screen.
  2. Add the field to a new screen.
  3. Add the new screen to a wokflow transition.
  4. Add a condition to the transition to enable it just for the appropriate users.

However, doing so without the help of a global looping transition counts with the same disadvantages previously shown in the section Use case: Triggering a post-function.

Thanks to the native global looping transition feature, controlling edit permission on the field level is both an easier and a more feasible task.


Daniel Eads Atlassian Team Aug 08, 2019

Great article! Other literature (namely Matt Doar's Practical Jira Administration) refers a transition that goes back to the same status as a looping transition, but the use of "to itself" as a target (the global part in your example) is new here as far as I've seen. That definitely does clean things up and make it more maintainable!

Other variations on the name I've seen in the past are "transition loop", "circular transition", "null transition", "self transition" - stuffing those here to improve searchability :)

Like Ignacio Pulgar likes this
Antonio Ferruz Community Leader Aug 08, 2019

"Learn something every day! " , I repeat that to myself everyday... and today .. you made my day!

I have been applying on multiple workflows some of the approaches , like the one mentioned by @Daniel Eads ,  that you have described in your article .. BUT you have opened  my mind to new option. 
Never thought about, great article . 

I work on workflows most of my days .. I am sure I will use your article as a reference soon. 


Like Ignacio Pulgar likes this

Great job!! Thanks for sharing with the community!!

Like Ignacio Pulgar likes this

Thank you all!

@Daniel Eads I like the term looping transition. My vote for Atlassian officially naming it that way! 😃

@Antonio Ferruz Glad you liked it! 😉

@Fabian A_ Lopez _Community Leader - Argentina_ Florida_ California_ I enjoyed reading your articles too! 😊

Great article!!

It will be very useful.

Thank you @Ignacio Pulgar !!

Like Ignacio Pulgar likes this
Rachel Wright Community Leader Aug 12, 2019

Excellent work @Ignacio Pulgar !  I also use the term "looping transition" but I'm not sure where I got that from  Maybe from Matt Doar?

I'll be passing through Madrid next month and will wave to you from a distance.  Keep up the good work!

Like Ignacio Pulgar likes this
Ignacio Pulgar Community Leader Aug 13, 2019

Thank you @Rachel Wright ! It's an honor reading those words from such a reknown author!

I'll feel the Force next month! :)

I think I got the term "looping transition" from Rachel. It's clearer than "(global) self-transition" which I was using before that.

Like Ignacio Pulgar likes this
Ignacio Pulgar Community Leader Aug 13, 2019

By popular demand, I've edited the article by substituting the term reflexive with the clearer and most extended term looping.

Ignacio Pulgar Community Leader Aug 14, 2019

If you think global looping transitions rock, please, vote for this suggestion so that all Jira admins can easily discover this feature while designing workflows.

Antoine Berry Community Leader Aug 26, 2019

And here I stand like a fool having developed a groovy function that automatically transitions to the last status. Great feature !

Ignacio Pulgar Community Leader Aug 27, 2019

Thanks @Yolanda Sánchez !

@Antoine BerryIndeed! If only it were more visible... That's why I recently created this feature request:

Please, vote for it to make Jira an even better product! :)

Lesson 1: don't use the "next gen projects"! 

Add this feature!

Like Ignacio Pulgar likes this

It's a neat function, but I am not sure how I would ever use it personally.

Anyone have a usecase where you use something like this so I can get a grasp on it's use?

Like Ignacio Pulgar likes this

Hello @Ignacio Pulgar Could you provide a practical example for the less experienced in Jira like me?


Like Ignacio Pulgar likes this
Esther Strom Community Leader Aug 28, 2019

Just curious how this would look now that we're using the new view on Cloud - we no longer have individual buttons for transitions; just a single dropdown.

Like Ignacio Pulgar likes this
Ignacio Pulgar Community Leader Aug 29, 2019

@Esther StromPlease, note there's currently a bug with global looping transitions on Cloud instances with the new issue view: JRACLOUD-72667.

@Jimi Wikman& @Luiz Carlos Maia Junior The simplest use case I can think of would be restricting the edition of the Priority field so that only users in Administrators project role could edit it, while other users retain the ability to edit any other fields:

  1. Remove the Priority field from the screen associated to the Edit operation.
  2. Create a new screen, ie named Prioritize Screen, and add Priority field to it.
  3. Create a global looping transition named Prioritize.
  4. Reload the workflow editor in your browser.
  5. Add the Prioritize Screen to the transition.
  6. Add the User Is In Project Role condition to the transition and select the Administrators project role.
  7. Publish your workflow changes.

That's a really simple use case based on restriction.

Let's see a different requirement: I want to be notified whenever my custom field change, but I do not want receive notifications every time the issue is edited.

A quite similar set of steps could be followed to implement this requirement, except this would also require to:

  • Substitute the Priority field with your custom field for all screen changes.
  • Name the transition in a descriptive way.
  • Create a custom event.
  • Add who will be notified of the custom event by editing the appropriate Notification Scheme.
  • Change the event type set to be fired by the transition to the newly created custom event.

This kind of requirement could alternatively be covered by a filter subscription for those system fields that support the CHANGED operator.

Please, note that:

  • Multiple post-functions and conditions can be added to one global looping transition, including those provided by third party applications. Provided the number of apps in the marketplace, the possibilies are almost limitless.
  • Adding to a global looping transition a post-function with custom script code which read the values given to issue fields allow to perform automatic actions relevant for said issue. Even more fields could be included in a screen, added to the very same transition, and acting as dynamic parameters in your script.
  • On certain circumstances, properly set global looping transitions may remove the need for using Script Listeners (ScriptRunner feature).

Global looping transitions add a lot of value to solve complex real-world requirements:

  • Creation of invoices from issues.
  • Integrations with third party tools.
  • ...and anything you can think of that should be triggerable from an issue, disregarding its status (note that conditions could be added to exclude availability from certain statuses too).

All these use cases could also be achieved through the use of other kind of transitions, but only global looping ones allow to implement them in a simple, maintainable and efficient way.

Ignacio Pulgar Community Leader Mar 21, 2020

Jira Cloud has recently been boosted with Automation natively.

So, many use cases may fit better in a manually triggered rule than in a global looping transition.

The automation rule may be executed by entering the Rule executions menu > <your automation rule>.


I have added one of these global loops for marking an issue as Product Owner Approved.  It simply updates a custom date field with the current date.  However, I don't see the transition appear as an option in the issue screen.  Was this forgotten with all the screen shuffling in the last years?

Like Ignacio Pulgar likes this
Ignacio Pulgar Community Leader May 14, 2020

Hi @Todd Hanson ,

Are you on a Jira Cloud instance? If so, I regret to say that's a known issue tracked in JRACLOUD-72667.


@Ignacio Pulgar thank you for your response! I will comment on the issue for why I would like this to be fixed.  I do have a workaround for now.

Like Ignacio Pulgar likes this

Witty¡¡, I love.

Great job

Thank you
A greeting

Like Ignacio Pulgar likes this


Log in or Sign up to comment

Atlassian Community Events