In a single Jira instance we have 3 projects and each project has a single workflow. Each workflow is very different from the the other 2. The 3 projects and workflows were created weeks or months apart by different people.
We just noticed for a single specific state in each workflow, when we change the status label, it is changed in each of the 3 workflows. In other words, if we changed IN REVIEW to SUBMITTED, each IN REVIEW state is changed to SUBMITTED in each of the workflows.
What we expected was IN REVIEW would only be changed in workflow that was being edited - not in all 3. Any ideas as to why this is happening?
Hello @James Malgieri status names are shared across the whole environment allowing you to reuse it in multiple workflows. If you want to rename it in only one workflow then you will have to replace that status for another with the name you want, not rename the existing one
OK - Fair enough.
In one of the Altassian documents about workflows is says, "Reuse existing statuses whenever possible and add new ones sparingly."
I'm beginning to think that is not such a great idea.
Thank You, Hernan.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
In most of the cases, the less the better.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You should reuse where it makes sense to do so.
Imagine trying to work out a report that could include 900 slightly different status for example? Or working in an organisation where the person next to you uses different words (in your shared language) for things that are in the same place in a process?
Jira lets you work in teams with differences, but at scale, you should be trying to be consistent too. It's a hard balancing act.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I agree but Atlassian doesn't do a good job of pointing out what Hernan states, "status names are shared across the whole environment." and if you change the label in one workflow you change it in all workflows.
The workflow training I've taken focused mainly on transitions. There are few, if any, examples of using the same status label in multiple workflows or the relationship between steps and status labels and their application in an instance having multple projects and workflows. The state I asked about was found in 3 workflows in the projects in a single instance. I might have expected all 3 to have changed if a signle project had 3 workflows but I never expected a change to occur in 3 different projects.
The best information regarding steps and state labels has been from searching online. For example, from this fellow - whose information needs repeating:
Nic Brough {Adaptavist} COMMUNITY LEADER Jul 20, 2014
Step is a position in a workflow, status is what you want to show to the users when an issue is on that step.There's a 1:1 relationship between them, which often confuses new admins and your next question is going to be "then why have both?" - the answer is that in the workflow, the step is the important thing, the status is just a label, but Jira does a lot more with status so there's a whole load of coding around status that makes it a lot more simple if the two are separate logical entities with a simple link.
Your users will only see the status, steps don't matter to them. I think of steps as a "skeleton" which you hang the rest of the workfow settings off.
Nic Brough {Adaptavist} COMMUNITY LEADER Jul 20, 2014
Status is not "more important" than steps, they're different things. It is important to remember that your users generally won't see steps, only status. But nothing would work without steps, so they're still necessary.For your second question, you're getting confused. Workflows have TWO important and very different components.
STEPS are an indication of where an issue is in the workflow. They are associated with a status, as we've already discussed. Two pieces of advice I'd give you about steps
1. Initially, try to name them the same as the status you intend to use them with. That will make it easier to see and understand. Even as an experienced admin, I find it useful to keep them at least similar
2. When choosing the name of a status, remember that it is a description of a point in a process flow. In English (I'm ashamed to say that I don't speak any other language), the sentence you should aim for is "<issue> is <status>". So I can say "issue is open", "issue is blocked", "issue is under reveiew"
TRANSITIONS are an action that moves an issue from one status to another. You should name them in a way that indicates an action. It's a verb rather than a descriptive word. You "close" issues, or "resolve" them, or "reopen" them, or, for more complex flows "put under review" or "give to a developer"
I am sure I am not the oly person or team who has run into the multiple workflows sharing a status/state label situation.
Thank You @Hernan Halabi - Elite IT Consulting Group and @Nic Brough -Adaptavist- for your inputs.
Jim
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I agree with you on the point that it doesn't warn you enough (or at all!). I'd argue for at least a red flag with "are you sure? X other workflows/projects will be affected by it"
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.