Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Deleted user
0 / 0 points
badges earned

Your Points Tracker
  • Global
  • Feed

Badge for your thoughts?

You're enrolled in our new beta rewards program. Join our group to get the inside scoop and share your feedback.

Join group
Give the gift of kudos
You have 0 kudos available to give
Who do you want to recognize?
Why do you want to recognize them?
Great job appreciating your peers!
Check back soon to give more kudos.

Past Kudos Given
No kudos given
You haven't given any kudos yet. Share the love above and you'll see it here.

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Statuses and Transitions

Statuses and transitions are shared between each project and workflow.


Currently, our status is shared on over 90 different workflows.


However as there are different projects within these workflows, they have different requirements, how does anyone else deal with this?


Instead of adding a large prefix such as "Project-Dragonboat Ready for QA"



How do other instances have this setup? I am trying to create the best JIRA instance for our developers however with the names very similar, one project requests a change, then another project requests the change back.


I cannot find best practises etc for this, so thought the online community may be able to help me with this 


Any thoughts?

1 comment

Take all of the following with a grain of salt. Im not very experienced yet myself:

There is no need for a "Project-Dragonboat Ready for QA" as well as a "Project-Butterfly Ready for QA"status. "Ready for QA" is enough for both usually. If you want to restrict reports and such you can use JQL to specify the project later.

If, on the other hand, Project-Butterfly needs a "Ready for Flying" status, and Project-Dragonboat needs a "Ready for Rowing" status, then you would have to associate 2 different workflows with the 2 projects (and create/use the respective status in there).

I beg anyone with more experience to chime in here, because im a noob myself with oh so much to learn still.

Thank you for the message Michael, I am in a similar situation as I am new to JIRA myself, I am aware we can share statuses and transitions but I believe I need to move away from shared statuses due to what I mention in the below paragraphs, currently, we have 3 or 4 statuses ("Done" for example) which is shared among 100 workflows, "Ready for QA" shared among 80-90 odd workflows.

We don't have any Change management for JIRA. 

Currently, I am the only person administering JIRA, due to workflows sharing all these statuses, we get some developers requesting changes to workflows, or new projects starting with specific requirements and we implement these changes, adding specific validators for that new project into their statuses and transitions.

A few days/hours later several developers log angry tickets that we changed their workflows, however, we did not change them intentionally, we find out afterwards that they are shared.


I have picked up a half-baked JIRA and been told to manage/administer it. Before I continue I would like to find out the best way forward, this is the idea behind this discussion, I would like to encourage anyone with little or a lot to continue this discussion!

adding specific validators for that new project into their statuses and transitions

If this is the requirements for a new project or change to an existing one, then it cannot and should not be done with a shared workflow since, as you already discovered, this has effects on all the projects that use this workflow.

You have to create a new one for this project in this case.

the best way forward

My two cents: Leave the old workflow as it is. Keep using this one (if there are no problems with it) for projects that work well with the already shared workflow. Then create another workflow for the project that needs special conditions/validators/statuses so you can satisfy their needs and associate it with that project. By doing that, you can add statuses, conditions, validators, post functions and whatever more you want without having any effect on the workflow that is currently shared between many projects.


This may be a lot of work, depending on how many projects with unique requirements you have. I do not think that there is a way around that.


Log in or Sign up to comment

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you