You cannot perform this operation on a draft workflow


As a JIRA administrator, I have several times edited and updated the workflow that our projects are using.

Today, when trying to edit the workflow and adding new transitions from "backlog" to "open" I'm getting the following error:

You cannot perform this operation on a draft workflow. More Information.

(where "more information" leads to the confluence page of editing workflows)

I don't understand what I'm doing wrong as it is clear that I'm working on a draft workflow that I will need to publish later on.




14 answers

This widget could not be displayed.

Ahh so to correct the default service desk workflow and add a single transition I have to create a whole new workflow, assign all existing issues to it? That is ridiculous. 

the time required to research and get around this is crazy. I like the modular approach of jira, but this is nuts and very frustrating.

This widget could not be displayed.

I will show the monetary importance of this bug by using a very simple and real user journey map in the hope that Atlassian better understand the problem and prioritize it higher in their own product roadmap:

  • Stakeholder is shown all the customization options and Jira's powerful abilities to customize
  • Stakeholder decides to start a trial with Jira
  • Stakeholder starts a new project in Jira
  • Stakeholder tries to add a single status & transition to the default workflow, then save.
  • Denied. "You cannot perform this operation on a draft workflow. {More Information}"
  • Stakeholder looks at {More Information} link in error message.
  • {More Information} link is not as helpful as the other link that should have been used, as Stakeholder spends a few minutes reading about workflows.
  • Stakeholder reads: "When you edit an active workflow, JIRA first creates a draft of it, that you can then modify as you see fit," and glances over the information contained in the buried show/hide link that follows {Editing limitations...}.
  • Stakeholder searches the web for a solution to this seemingly basic customization and finds this forum and is dismayed that this little problem is taking a long time. And starts to reconsider this product he/she is wrestling with.
  • After reading the forum from users, the Stakeholder finally finds the workaround solution!
  • Stakeholder then navigates to workflows, duplicates the current (default) workflow, changes the name of the duplicated workflow (but can't use the default name since it is the active one), adds the status and names it, adds the transition and names it, navigates to the workflow scheme, changes the workflow in the scheme, navigates back to workflows, then finally deletes the default workflow.
  • Stakeholder sits back in his/her chair and imagines the nightmare of
    • A. doing that again for multiple projects
    • B. teaching others this very basic and essential customization that turned out to be a complete headache
    • remembering how to do the 9-step workaround to this bug after a couple months
  • Stakeholder decides to not go through with Atlassian and does not spend money

It is legit insane that this issue still exists. Want to add a Reopen status to a brand new project? Too bad! You can't transition from Published for some reason. How did nobody not notice and then fix this years ago?

Or at least allow you to set up the workflow as part of the project create process.

The new, incredibly obtuse interface where you hide everything doesn't help matters. 

That is EXACTLY what just happened to me. I was investigating if I'm going to use Jira for one of my projects, started trial, tried to set up the workflow and realized that it's too much efforts in fact. Not going to pay Atlassian after the trial sorry. This (and a number of other ridiculous issues like no way to put your own url for the cloud version or ridiculously high system requirements for the server version) is a total game stopper for me.

This widget could not be displayed.


in your case you're running into a known issue. You can't add outgoing transitions to final statuses.

If you want to work your way around this: 

  1. Create new workflow as a copy (that way it will be inactive)
  2. Add in all the transitions you need
  3. Associate the workflow with your scheme and the issue types again to activate it
  4. Run through the wizard
  5. Done

Another thing you can't do on active workflows (drafts) is to delete statuses

What you mean by "final statuses"? I have just created fresh copy of JIRA and I can not connect anything to the TO DO status. How is it final? How do I unfinal it?


Most importantly, why is the error message so unhelpful?


Why such arbitrary limitation?

Why is the error message so unhelpful?

A known issue since Jul 2015 that apparently is still in the system. Considering the price tag you guys put on your products, I'd expect some of the basic issues (e.g. setting up a new workflow or changing the existing one) to be flawless.

Thank you Christian Czaia, your comment helped me

@Enrico Foschi I agree. The more I bump into some ridiculous issues in managing Jira/Confluence, the more I realize how unprofessional Atlassian is.

This widget could not be displayed.

Please fix.  If this is working as expected then please round up the people who designed this and the people who approved that design, put them in a room with a door, close that door, lock it, and never go back.

It's on the list, but it's way way down the priorities from what I hear.

Time for a change in priorities. This is TERRIBLE. AWFUL. And I thought RALLY had quirks. This is just anti-user. It is sadistic. 

This widget could not be displayed.

This horrible bug is still present, please fix it. 

Yep... appearently, and it's over 2 years...

For me it's not worth adding the "Undo review" transition from "Done" to "In review", so we have to live with an out-of-date-workflow.

The workflow is shared by 5 projects, so it will be quite some work to disable the workflow and reeneble it again...

Imagine my pain trying to update a shared workflow across 12 projects 😥

This widget could not be displayed.


When editing a draft worflow, some statuses/steps cannot be deleted and outgoing transitions cannot be added. This makes these steps and statuses useless.


JIRA contains specific code that removes the ability to perform these edits to occur on draft workflows.


A snippet from the workflow documentation:

Limitations when editing an active workflow

Please note that the following limitations apply when editing an active workflow (i.e. a draft workflow):

It is not possible to edit the workflow name (only the description) if a workflow is active.
Workflow steps cannot be deleted.
A step's associated Status cannot be edited.
If a step has no outgoing transitions (Global transitions are not considered), it cannot have any new outgoing transitions added.
A step's Step ID cannot be changed.


There are two different options:

  1. Publish the workflow after all steps are populated with transitions.
  2. Edit the workflow in a disabled state (either copy it or disable the workflow scheme).



I just ran into the same issue. I was able to create a new status and transition just fine at first. Then I published the draft and decided to go back and edit the workflow again. Now it's telling me I can't add a transition, which is strange since I was able to do it a few minutes earlier. There's got to be an explaination for this.

This widget could not be displayed.

This is incredibly non-intuitive. I just went through the process of making a new workflow and then moving all of the items over to it. I just copied my original bug workflow and named the new one Original Name (v2).

This really should be much simplier, once a draft is published it should push you through the reassignment process (if needed). I don't know why Jira has to overcomplicate everything so much.

 It reeks of a process dictated by engineering limitations. It certainly has nothing to do with how users work. #UXFail

This widget could not be displayed.

Unacceptable that this is still a bug.

It's unacceptable for someone to assume that their one bug is more important than the other bugs and improvements the rest of the users want fixed - ones that don't have work-arounds or will make very large improvements for lots of users rather than just an admin.

Please don't make judgement calls like that - it's unfair and demanding, without being useful.  I can point at hundreds of things in Atlassian software that are far more important to me than this one, but our opinions as end-users have the same weight.

I also find it a turn off to adding content to this community when the "community champions" are adversarial and edit messages several times in the middle of the night to generate lots of email spam causing users to unwatch message threads so things continue to get ignored.

Joe Pitt Community Champion Jun 26, 2018

Technically it isn't a 'bug'. It was designed that way. A bug is something that doesn't meet requirements. In this case it doesn't meet what some people want.

Workflows often span multiple projects and they didn't want certain things to be allowed because it may break the workflow. Creating a new one so you can go back to the old provides protection. I've been working in IT since 1983 and people are very bad about backing things up. 

I don't think I was any more adversarial than someone yelling "unacceptable" instead of giving a reasoned argument as to why this one bug with a work-around is more important than the needs of others.  The edits were because I was being grumpy, because I don't like being told my opinion is worthless.

As for the edits - it's my morning here.  I can't stop you getting emails in the middle of the night if you've subscribed, sorry.  Email batching and being able to get finer-grained control of the mail is something that comes up with the community leads regularly, and is something that we'd like to improve.

Nic, nobody is saying that this is the most important bug for atlassian to fix, that was something you made up and then got mad about....

Perhaps Atlassian needs to reevaluate their 'community champions' if they can't understand the frustrations of the community. People find this page after hours of trying to figure out why this issue with basic functionality exists and how to work around it. It is understandable that they will be frustrated after learning that people complained about it nearly THREE years ago.

This sort response by a community champion is what I see for nearly all bugs/features such as this and its really making me unsure as to who this support community is for -- users of Jira or people paid by Atlassian to get mad whenever someone has a suggestion or request. 

Right now, I am attempting to to edit a workflow. Its a small team of 5 people on one of our boards, and they had a request of the change of workflow. It was a simple ask. The concept in my own mind was simple. Even navigating to the page to do what I wanted to do was three clicks total. It was one click and drag to do it. 

What I wanted to do was clear and easy both in my mind and within Jira.

However, Jira decided that this clear concept cannot be done. But why? 

There is an endless and needless attempt by Jira to protect its users from making mistakes. But in this exact instance, it wasn't a mistake.  

There are even simple ways to handle this situation:

  1. Warn people heavily about the action they are going to make (you know, explain to me why I can't do this? Let me acknowledge that I can do it?)
  2. _Automatically_ create a backup when users take this action (If its such a scary thing then protect me for me. If it breaks something the backup is there no matter what). 
  3. As an admin me an option that allows my workflow managers to take this action. 

But the crux of this problem is that its been here for three years. Three years. It is entirely fair to call this issue remaining unhandled and unanswered unacceptable. What makes it further ridiculous is that instead of offering up actual solutions or reasoning to this, the wonderful community champion Nic Brough has flown in to inform us that he is offended on Jira's behalf that people will genuinely look elsewhere at tools due to this bug. 

The simplicity of what I am trying to do is the same as creating a subtask on an issue. Its a single click and drag. But we're not allowed to do it. And there has not been a single explanation as to why.

Given the absolute simplicity of the overall problem its especially frustrating. 

There are requests and bugs in Atlassian software that are

  • A lot older. 
  • Affect a lot more people
  • Do not have workarounds

And are hence far more important than your opinion.

3 years is not unusual, and simply reflects that the opinion of the users and product managers is that there are lots of other things that are more important and more "unacceptable".   Jira 7.6 finally implemented something that MCB reported 15 years earlier.  15.

By yelling "unacceptable", you're venting, not contributing.  Have you come up with any other workarounds than simply copying and editing?  Written an add-on to fix it?  Contacted your TAM if you have one?  Voted on the issue(s) the record the issues in JaC?

Its alright Nic I'll just wait until 2030 to get an explanation for this one I guess. 

Yeah, we might have to.  I know it's frustrating, but my point is not that it doesn't need fixing, just that there are other more important things to do.

This widget could not be displayed.

I have the same problem. I'm not able to add a direct transition from a closed status to a to-do status. The solution on my case was to add a global transition to the to-do status by selecting the checkbox in the right "Allow all statuses to transition to this one" and then modify the post functions of the transition to clear the resolution field and this reopened my tickets without any problem.


I know that this shouldn't be the final solution but is a quick fix if you need to reopen some tickets, you can delete the transition after moving the tickets to the to-do column.

This widget could not be displayed.

This is terrible, please fix it.

Ditto. It's insane.

This widget could not be displayed.

Still has the bug? LOL I'm going to end the subscription and use another software. 

Wow, that's impressive.  You want to swap to an alternative system because of a trivial bug that only affects admins and is easy to work around? 

Don't get me wrong, it is silly, and I want it fixed, as I spend a lot of time fixing workflows.  But switching to a vastly inferior system because of it is a lot more silly.

with our recent run in with the changes and inconsistencies to the renderers, added to this type of situation where a change that breaks expected behavior and creates more work to in turn be ignored for years. If there was a viable alternative, we would also switch.

I can honestly say atlassian is creating jobs, in that we have an intern that usually deals with this because we were spending 3 to 5 times as much as our subscription costs in skilled labor performing these types of workarounds.

Our admins/devops dislike the product, our devs try their best to avoid using it, the analysts complain weekly about it, customer service use it long enough to copy paste to a second system. Our jira intern hates using it but loves that he has a job. The only people that like it are the project managers because it has nice reports.

If atlassian isn't careful, someone is going to create an alternative and they will either have to acquire or watch subscribers jump ship, it is not a happy ecosystem they have going.

>Our admins/devops dislike the product, our devs try their best to avoid using it, the analysts complain weekly about it, customer service use it long enough to copy paste to a second system. Our jira intern hates using it but loves that he has a job.

That paragraph smacks of a Jira admin person or team that have not engaged with the users.  It's probably been "designed" by people who don't have to use it, and/or higher level people who thing they should enforce what they think is the right process by inflicting poor choices on the users.

Rather than trudge along hating it and wasting time on something that sounds broken, take a step back and re-evaluate.  Is it really the software?  Is it actually your processes?  Or the setup of the software?

Could you be objective about it?  Might it be better to get an Atlassian partner in to have a look at what is broken?  Or evaluate other products, bearing in mind the cost of massive change and having to re-integrate everything?

Might it be better to get an Atlassian partner in to have a look at what is broken?

Create more jobs 🙌


If atlassian isn't careful, someone is going to create an alternative and they will either have to acquire or watch subscribers jump ship

Case in point: Trello.

There are alternatives, but they don't meet the unproductive demands of executives because the alts are focused on productivity. And so the cycle of Atlassian's growth continues.

This widget could not be displayed.

Hi everyone,
If you have found this thread, then you are among a number of growing users that have hit their head on this limitation of editing active workflows.  By now, it must be clear to you all that editing active workflows have a number of restrictions that are not obvious to new Jira administrators nor are they clearly laid out/easy to find in the official Atlassian Documentation space.  For that, allow me to apologize on behalf of Atlassian.  Sorry about that.  We are working to improve this.

To help correct this, I actually believe that @Brian Pohuski's post is the best explanation of the problem that most users see when they encounter this error.   I found that Brian in turn then created a documentation update request over on JAC, please see
I believe that this request is actually the best place right now to vote for this issue.  Thanks @Brian Pohuski, appreciate your efforts here!  

Ultimately, I don't see a clear way to change the root behavior of making these specific types of changes to an active workflow.   There is actually a really high likelihood of data corruption/inconsistencies to allow users to edit an active workflow in the specific ways that trigger this error.   So I understand that many users that see this error believe it's a bug.  However I would ask that users that believe this is a bug take another look at this and try to see the potential problems this could cause from a data integrity aspect.   Suppose you already had a number of issues in a final state of Done, and then you changed the active workflow to have a new final state.  Suddenly your previous issues that were complete, have a resolution and are complete, but may never reach the newly created final stage in the updated workflow anymore.  To use the cliche, "It's not a bug, it's a feature" actually seems appropriate on some level here.  The fact that you see this error here, Jira has actually prevented you from doing something potentially unwanted to your own Jira data.  

In the mean time, the workaround of copying the existing active workflow, making the changes to that inactive copy workflow, and then associating that copied workflow with your project/issuetypes is really the best way to work past this limitation.   The process of applying a new workflow invokes a wizard that will help to move your issues to conform with this new workflow in ways that just does not happen when editing an active workflow directly.

Instead I think the more helpful means to progress this issue and be productive here is to update our documentation and better instruct/educate Jira administrator that are editing workflows here about this limitation.   It's clear to me from reviewing this thread that we, as Atlassians, have not done a good enough job on that front to date.  But I hope that this post helps to start to bridge that gap.




Hi Andy, 

I can't speak for everyone on this issue, but my concern is not editing a truly active workflow on an existing project, I understand the problems that could occur with that.

Rather, the problem for me is that you can't easily modify the workflow on NEW projects. I would think a very common process for people would be to create a new project and then tweak the workflow as needed. This would be before any issues are created. See Brian's post above.

Yeah, I understand that.  But from the moment a project is created in Jira, it has at least one active workflow in place.   Even if you haven't created issues yet in that project, it doesn't change the limitation in regards to what you can and cannot change in an active workflow.

@Andrew Heinzer

Thanks for taking time to answer, but your reply to Bill H above shows that you don't really grasp the true issue or the frustration we are experiencing. You mention one specific kind of change that could cause cards to be "orphaned", but that's a very specific case. This bug prevents a huge number of very simple, benign changes, even for projects that have no issues at all yet. How could there be a risk of "data corruption" in a project that has no issues? There are lots of other simple changes I'm prevented from making (adding new transitions, adding additional "Done" states, etc.) that carry zero risk of "data corruption".

Please don't sweep this under the rug as "working as designed, needs better documentation". Please listen to your users. Isn't that why you have this "Community" in the first place?

> Suppose you already had a number of issues in a final state of Done, and then you changed the active workflow to have a new final state.

Alright, let's think that through like a product development team ...

Can the system query all Projects using that Workflow for statuses that don't exist in the new edit? Yes.

Can the system present these statuses (and an issue count for each) for the user's review? Yes.

Can the system enable the user to change each missing status to something in the new Workflow? Yes.

It's much like moving an issue. Not elegant, perhaps, but better than the existing solution.

IOW, don't use "it's a feature" as an excuse for poor or incomplete design.

Hi @James Ryan,

Let me try to explain some more of the technical details behind this and I hope it might help explain my viewpoint better.   Workflows in Jira are stored in a SQL database.   Each status, and transition exist in specific entries of these SQL tables, and these elements in a workflow have unique identifiers and relations to each other.   There are elements here you can change in an active workflow that don't undermine these SQL relations.   But there are also elements here that if changed in an active workflow, would not then in turn update the specific jira issues that could be assigned to that workflow.  

I get it, "in a new project, what does it matter because I don't have issues yet?" 

Great question, and a good point.  But the checks that exist for active workflows are in place to prevent bigger potential problems, not just my one scenario.  Jira is not yet intelligent enough to make the check against an active workflow for issues assigned to that workflow to see if they are empty or not before letting you make these kinds of changes.   Instead workflows are all either active or inactive. Active = in use somewhere in Jira, inactive = not in use by any project/issuetype.

Since workflows can be shared across projects, checking one project would not be enough anyways.  Imagine having a Jira instance with 50 projects, each with 200,000 issues.   They could all be using the same workflow.  The check here would take a significant processing hit to complete against each project/issuetype in question.   Instead Jira is setup to check only if the workflow is active or inactive.  The number of issues potentially involved becomes irrelevant in this case.   I imagine it was designed this way for the sake of performance, but that's mostly a hunch.

But the process of associating a new workflow is at least able to check against existing issues and if their current states don't match the new transitions available.  If that happens, then Jira prompts the admin to assign these existing issues to new status instead.    This commonly has to happen when importing data from another system into Jira.

Please believe me; I do feel your frustrations over this problem.  It would be a better user experience if you could just make those changes directly.   But in my view the work-around of making these changes to an inactive workflow first and then assigning that to the issuetype are not that difficult to do, and in turn provide you these other protections of your Jira data.  

Forgive me if I am oversimplifying your argument here, but the trade off is avoid data loss for x number of Jira issues VERSUS save an admin 4-5 extra steps editing a workflow.  I believe the avoid data loss mantra reigns supreme.  I understand that you don't want to have to perform these extra steps to do. That's fair.  It is tedious.  It can be frustrating.   I too can feel the frustration around this.  

My intention is not to sweep your concerns under a rug as you put it, far from it.  But rather to help users that find this problem get past it one way or another.  If you feel a change to the code in Jira is the better long-term solution than simply making changes to inactive workflows first, then of course I invite you to create a suggestion on

Maybe I am in the wrong in my approach here.  I accept that I'm not perfect. I can't guarantee Atlassian would implement the changes suggested there, but I am open to listen.


First: I really appreciate the time you are taking to discuss that with us, going into details, and taking some heat for Atlassian (the heat is well deserved for Atlassian, and ultimately has to go to _someone_, thanks for stepping forward and taking it).

Second: With respect to: Jira is not yet intelligent enough to make the check against an active workflow for issues assigned to that workflow I say this is really just an SELECT with an SUM aggregate. It should take between a person-day and a person-week of engineering and QA time, depending on how knarly the SELECT is.

You mention the performance hit. The performance hit is NOTHING compared to the time it takes to have a JIRA admin take the steps they must take now to implement the work-around, IF you want to do it the way you specify. HUMANS are expensive. Machines are cheap.

Third: If a process can be implemented in a work-around as described, with: A) copy the workflow; B) make the change; C) apply the copied workflow to the project ... THEN it can be coded. That it isn't coded is a matter of priority by the Product Owner(s) at Atlassian. We get that. But, these other discussions about performance, etc. are distractions. Just implement the workaround in code. Oy. Take the work off the humans and put it on the machines. That is what the machines are FOR. It's why we pay for _software_. 

Finally: To "get past it" Atlassian needs to step up and provide a SOFTWARE solution, not a HUMAN solution. We pay $ for the software. Or we go find OTHER software that DOES solve our problem. Market forces at work.


I agree completely with @Matthew Thurmaier and was about to post something very similar. If the process of reactivating the workflow "provide you these other protections of your Jira data" (in the words of @Andrew Heinzer), then it sounds to me like you already have a solution that works in code. Just reuse that code as a verification step when editing active workflows, and eliminate the extra steps of having to deactivate and re-activate.

Also, @Andrew Heinzer, I think you need to remember your audience. JIRA users, by definition, know software development. It's what we do. You should use this forum as a resource. With respect, it sounds more like JIRA is just trying to placate us with excuses.

And if JIRA's position is "we have higher priorities" then just tell us that! This audience understands that better than any other.

Honestly at the end of the day I think we just need something better than a "You cannot do this" message, but instead a "You cannot do this, this is why, and here are the steps you should be taking to do this" message.

Would dissuade a lot of the frustrations we have, despite it still being silly overall. 

+1 to what Vic said, at the very least a better error message would be an improvement.

It took a lot of googling before I found this post and finally figured out what the problem was. It was a massive waste of time that could have been prevented by a better error message and link to documentation. 

I am here because I was trying to implement another of your workarounds because you can't bulk edit issues to add in a resolution:

However I was unable to add in a transition FROM a final state to itself. 
This would seem to be a different category of transition than the one that @Andrew Heinzer mentions above that might incur data loss.


In the end I just went ahead and manually edited a hundred or so issues in their final state to add in a resolution.

@Victor Vucicevich @Lindsay Brock

Agreed. I created a suggestion for that here: which is what @Andrew Heinzer was mentioning. If nothing else, at least it will help reduce some confusion.

Definitely could use some votes or more user input directly on that issue if you feel up to it!

This widget could not be displayed.
  1. I agree with @Matthew Thurmaier
  2. I've upvoted JRACLOUD-17782 - Allow to delete a step from an active workflow if there are no issues in that step. I'm not sure it's the whole solution though. For new projects without any issues, any changes should be OK.
This widget could not be displayed.

This still exists as of August 9, 2018.

The fact that I could create a new step and direct issues to it but be unable to direct issues out of it, is just... broken.

Unless a logical failure is detected, there should be absolutely no reason you can't add a new path for an issue to travel. The details and arguments have been fantastically stated by others during the month prior to my post. Thank you @Matthew Thurmaier and @James Ryan for saving me lot of typing.

## insert sharp, witty comment here, that I'm too tired to come up with right now.

Suggest an answer

Log in or Sign up to answer
Atlassian Summit 2018

Meet the community IRL

Atlassian Summit is an excellent opportunity for in-person support, training, and networking.

Learn more
Community showcase
Posted Aug 06, 2018 in Jira Service Desk

A is for Activate: Share your top Jira Service Desk onboarding tips for new users!

Hi, everyone! Molly here from the Jira Service Desk Product Marketing Team :).  In the spirit of this month's  august-challenge, we're sourcing stories of Jira Service Desk activation fro...

565 views 25 15
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