Jira Workflow Transition Types

[#1]

Introduction

While studying for my ACP-100 exam (Jira Administration for Data Center and Server, at the time of writing this article), I came across the names of 3 different Jira workflow transition types (there may be more!), outside of the usual one status -> transition -> one status.  I had a hard time tracking down much documentation on them.  So I thought I would share what I found for others studying for an exam or for those who just want to learn more about transitions.

3 Special Transition Types

1. Common

A common transition is one that two or more statuses use.

This one you've probably seen before.  When you add a transition, you click the Reuse a transition tab and select an existing transition to reuse.

---

---

2. Global

A global transition is one that can be transitioned to from any status in the workflow.

You've also probably seen this one but didn't know that it was called a global transition.  This transition is created by checking the box next to Allow all statuses to transition to this one.

---

---

3. Self-reflecting

A self-reflecting transition, transitions back to itself, not a different status.

You probably have not seen this one too often.  It took some digging to figure out what this transition does.  Some use cases for the self-reflecting transition are when you:

• Don't want the status to change
• Want to prompt the user to input data on a transition screen
• Want to put a post-function on the transition

I suppose that you could also use a self-reflecting transition if you didn't want to add more statuses to Jira but wanted to prompt the user to complete a step. The transition won't be recorded in the issue history, just that the status went back to itself.

---

---

You could get creative in how you implement a self-reflecting transition!

Sample Workflow

Here they all are together in a workflow with my added notes:

---

---

Conclusion

Now you know the names of those transitions you've been using.

I hope you found this article to be helpful.  If you did, please Like it!

And remember me when you get the question on the exam right. ;)

[Mikael Sandberg]

A good use case for the self-transitioning can be that you need something to happen before the issue can move forward. I have used it for Risk Assessment where the issue was not allowed to moved forward unless the CRB risk assessed the issue first. Because you are using a transition you can control who can perform that one, for example only users in a specific project role should be able to do it.

I have also used it to set the resolution on issues that where in a done status category but didn't have the resolution set. You can the add that as a post function to the transition.

[Matt Doar]

Good article! I see that @Rachel Wright's article at https://community.atlassian.com/t5/Jira-articles/How-to-create-global-looping-transitions-in-a-Jira-workflow/ba-p/1135968 had some good discussion about what to call the "self-transitioning" transitions. 

Did you find some Atlassian docs that use the word "self-transitioning"? I see @Ravi Sagar _Sparxsys_ uses that term too but I don't know where it came from.

Atlassian - pick a phrase, add it to some docs, please!

[Matt Doar]

Wait, you use the phrase "self-reflecting" as well. Now that is confusing!

[Joanna Thurmann]

@WW fantastic write-up. And thanks for your input @Matt Doar.

They are most commonly referred to as self-reflecting, loop, or looping transitions. On the exams, they are called "self-reflecting". 

[Dirk Ronsmans]

nice article :) always good to get some clarification on terms we just use casually.

I tend to use self-reflecting transitions indeed mainly when I want to show a transition screen with fields that only a specific group/user should have access to. By limiting the transition itself it's an easy way to block the fields.

[WW]

Hi @Matt Doar ,

The word "self-reflecting" (which I somehow renamed to self-transitioning*) came from the ACP-100 Jira cert prep course study materials.  That's where all three of the names of the transition types came from.  I searched and searched for something about self-reflecting transitions, and had to infer from some posts that indirectly mentioned self-reflecting transitions and one youtube video on it.

That article you linked to looks like a good one.  I've never heard of global looping transitions, but they seem to be another type of transition where it's a self-reflecting transition on a global transition.  

*I have no idea why I renamed self-reflecting to self-transitioning.  Maybe I saw it somewhere, or maybe I got transition happy. :)  I went ahead and updated the terminology so that it's all the same now.

[Yi Meng]

@WW 

is it still valid to add a self-reflecting transition in Jira Cloud workflow now? I tried to add this kind of transition in my workflow but it's not working. No condition set. 

[WW]

Good question. I do not know. This was for the Jira Data Center (and Server at the time) certification exam.

[Mikael Sandberg]

There is still good use cases for self-transitioning/self-reflecting transitions. I wrote an article about adding approvals to a Work Management project that doesn't have the approval feature (only available in team-managed projects) that is using the self-transition to log the approval/denies.

[Federico Rava]

is it possible to create a Globa transition that can transition to any other status?
All > In progress > ALL?
Thank you

[WW]

Hi @Federico Rava ,

Apparently so, if I'm understanding your question correctly. I saw one of the projects in our instances had one, so I tested it. This is how it's done:

In the workflow in Edit mode, click the Add transition button:

---

---

Then select:

• From status = Any status
• To status = Itself

---

---

This is what it looks like alongside the rest of the workflow, just sitting there by itself:

---

[Federico Rava]

Hi @WW

 I was really impressed with how you hit the nail on the head!
That was exactly what I was talking about, a transaction that allowed you to switch from one state to all the others (and not just input as I had already seen thanks to this tick):

If I understand what you're saying correctly, in a nutshell if I transition a state to itself this actually has the same effect as if there was an outgoing arrow to all other states, who knew!

My team thanks you very much.
Have a nice day :)

[Federico Rava]

Hello again @WW , I think i misunderstood what you were sayng, 
I made a non sense workflow to have an example, here it is: 

As you can see i configured the "in progress" stauts this way:
- all other statuses can transition to it (by the tick in prev comment)
- and i added the transition to "itself" as you were suggesting.

the behaviour I would expect from this ‘itself’ transition is as follows:
- The state can transition to all other states, and thanks to a screen and a validator (field required) assigned to the transition, I would like the possibility for the user to fill in a specific field to appear on the screen.

I can create the screen for the opposite direction : *ALL => in progress.*
But when I try to use ‘Itself’, at the end of the day the issue in this case can no longer leave the ‘in progress’ state.

so it seems to me that in the end ‘itself’ really means ‘towards itself’, right?

I hope I have explained myself this time.
Thank you for your time

[WW]

Not exactly. It works for transitions, not statuses, or at least I haven't tried with statuses.

[Federico Rava]

uff, sooo, do you think that my idea isn't possible too?

[Chris Buzon]

A good and useful case for Transitioning a ticket back into itself (Self-Reflecting) is when you're applying resolutions to Done StatusCategory tickets (as you should be doing with all Done statusCategory statuses).  The trick is to limit the number of resolutions in your site to meaningful ones, then use resolution to differentiate flavors of done-ness (like duplicate, vs Cannot Repro, vs Done vs Won't do).

Since you cannot directly edit resolution in a status, you can use a self-reflecting transition to update it.

If you create a unique screen (I call mine Simple Resolution Screen - and then add resolution, and any other useful fields you want to it), and add a self-reflecting transition for the final status in your workflow(s), you can use it to pop open the Simple Resolution Screen in the transition without reopening the ticket -- though you ARE updating the Resolved time when you do this.  This action is pretty easy to chain into other things, like automation rules, so it's quite powerful if you're looking to ensure high quality data.

We have lots of use cases built on the same principle, but an "update resolution" action in a Done statusCategory ticket that allows you to edit the resolution is a game changer for teams.