Is it possible to change the name of the "Resolved" status without losing functionality?

There is a request to change "Resolved" to "Code Complete" in a workflow we use.  It seems like there is specialized functionality tied to the "Resolved" state.  Changing the step name doesn't do a bloody thing.

So it seems the only way I can do this is to create a copy of the workflow and remove "Resolved" and add a new state, and then recreate all the transitions with all of the conditions, post functions, etc.  

Or is there a way to just swap in a new state?

3 answers

0 votes
Steven Behnke Community Champion Jun 10, 2016

I would not rename the Resolved Step or the Resolved status. Keep in mind that this is different than the Resolution field.

I would perform the following steps – 

  1. Copy the workflow
  2. Add GreenCode Complete status to the workflow
  3. Using the Graphic Designer, drag all transitions that begin or end with Greenresolved to the new GreenCode Complete status
  4. Copy any State Properties to the new status, if there are any
  5. Remove the Greenresolved status from the workflow
  6. Assign the workflow to the workflow scheme
  7. Migrate your issues


But will I lose functionality, such as the created vs. resolved chart?


As for the graphic designer... if only I could use that.  My version is too old sad

Steven Behnke Community Champion Jun 10, 2016

Oh! What version are you using? That's important.

The Created vs Resolved chart is PURELY based on whether or not a value is set in the Resolution field. The reason Resolved is named such is because you usually SET the Resolution when navigating to the Resolved status.

When navigating to Code Complete, be sure you bring up a Screen with the Resolution field on it. When navigating from Code Complete to an open status, be sure to clear the Resolution field. This will maintain the Created vs Resolved chart.

Hmmm.... prior to getting any answers here I made a quick & dirty workflow where I added a "Code Complete" step and edited the transitions to Resolved to point to that state, and moved the outgoing transitions, so for all intents and purposes the new state replaced Resolved.  I then transitioned a bunch of tickets to that state, changing their resolution to fixed.  I got no new issues on that chart.

Turns out the ticket I used was very old, which brings up another interesting, but mostly unrelated point - newly resolved items don't appear if they were created over 30 days ago.

JIRA prevents you from removing statuses in an active workflow. That has nothing to do with the Resolved status itself. Any status behaves like that.

But even though you do have to create a copy of your workflow, you don't have to redo your transitions. You can easily add the Code Complete status, re-route your transitions that pointed to Resolved to Code Complete instead. and only when you've isolated Resolved do you delete it. Then you swap the old workflow with the new one in the workflow scheme and go through the migration wizard. I've done this a hundred times, it works perfectly every time.

But will I lose functionality, such as the created vs. resolved chart?

Primarily, you could have renamed the status in JIRA administration using edit option. But, this change will reflect in all the projects in the JIRA instance, which is pretty risky.

I would support your path. It is better to take a copy of workflow, create new status and associate it with new transitions. It is a safe action. But you have to make sure two things are right.


  • The  status name or status Id of "Resolved" are not used anywhere in the scripts.
  • The  transition name or transition Id from "Resolved" are not used anywhere in the scripts.
    If used, these has to be modified with new Ids.

But will I lose functionality, such as the created vs. resolved chart?

Sorry, I didn't understand your functionality 'created vs. resolved chart'.

Suggest an answer

Log in or Sign up to answer
Community showcase
Posted Oct 09, 2018 in Jira Core

How to manage many similar workflows?

I have multiple projects that use variations of the same base workflow. The variations depend on the requirements of the project or issue type. The variations mostly come in the form of new statuses ...

397 views 6 0
Join discussion

Atlassian User Groups

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

Find a group

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

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you