Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Why can't I make changes on my DRAFT workflow?

JIRA, you're killing me!

While trying to add transitions to workflows, I keep getting error messages like:

"You cannot perform this operation on a draft workflow." (while trying to add a new transition)

"You are editing a draft workflow.  The step "[stepname]" has no outgoing transitions in the Active workflow, so you cannot add any outgoing transitions in the Draft workflow." (while trying to publish a draft workflow - and adding an outgoing transition is PRECISELY what I was trying to do!)

This makes no sense.  It's like it's asking me to change an ACTIVE workflow, which I can only do while in DRAFT, then it fails.  I can't see any way around this.  Is this a bug?  If so, when can a fix be expected??

12 answers

2 accepted

Comments for this post are closed

Community moderators have prevented the ability to post new answers.

Post a new question

60 votes
Answer accepted

Hello Friends,

You cannot edit the workflow because it is "Active", means it is already assigned to a Project.
(even if workflow is Active you can make little changes, like renaming Status/Transition)

Here is the Solution (it worked for me every time)

- Go to Edit the workflow
- Try to publish (without change) and Create a backup copy there

- Go to JIRA Settings -> Issues -> Workflows
- Go to Inactive Workflow section and try to Edit the workflow that you just created as a backup
- Make the changes and keep the window as it is (you may not find the option to save anything there)

- In a separate window, go to Project Settings -> Workflows
- Go to Add Workflow and select the same Workflow that you just edited in separate window
- Click few Next buttons, if there is no new Status it will probably not ask to match the status between Old and new workflows
- Publish it and your are Done (Close the other window where you still opened that Workflow in Edit mode)


Hopefully it will work for you.

Yes, that's the long version of what we've already said.

Like Emre Ciftci likes this

Thanks for this thorough explanation - it did the trick!

Like # people like this

Thanks this saved my day!

Like Pankaj Verma likes this

Sir, thank you, Sir!

Like Pankaj Verma likes this


I'm trying to follow these steps but I can't create the new Workflow with the same name. 

Any ideas?

Create the workflow with a different name, then rename it after you've removed or renamed the old one.

Like Pankaj Verma likes this

This should be the accepted answer. Since this is low priority for Atlassian, at least the step-by-step workaround should be easily available. Thanks, @Pankaj Verma! Saved my day.

Like # people like this

Pankaj's response should be added to Atlassian documentation.

Like # people like this

Thanks Pankaj Verma :) 

Like Pankaj Verma likes this

Thanks very much for the help. This worked perfectly for me now.

Like Pankaj Verma likes this

Making the workflow INACTIVE helped me.

Here's my workaround:

  1. Go to Settings > Issues > Workflow schemes
  2. Remove the workflow from the scheme to make it INACTIVE
  3. Edit INACTIVE workflow
  4. Go back to the workflow scheme and bind the workflow with Add Workflow
Like # people like this

Thanks, It worked!

Despite this being the "long version of what was already said", this was the only clear version of how to pull off this absurd workaround.  Agree with all the kudos here, thanks @Pankaj Verma and everyone on this thread attempting to help explain how to do this. 

If an official fix is not something Atlassian wants to do, at least proper documentation (complete with screenshots) would be nice on how to perform what really is not an edge use case.

Like # people like this
25 votes
Answer accepted

There's a long-standing howling bug in the workflow editor in that it can only add a transition to steps that already have outgoing transitions.

We've been waiting for a fix since the workflow editor got "draft" mode, and I'm afraid it seems to be a very low priority for Atlassian.  So there's no fix forthcoming any time soon, and we can't plan on one being released ever.

I'm afraid you will need to work on a copy and migrate.

My heart is breaking

Like # people like this

This is seriously flawed - this issue makes it stupidly difficult to add a transition.

Atlasssian seriously, c'mon!!!!

Like # people like this

This popped up for me when a user placed an Issue in our new specified "Done" status. So I thought to be smart and edit the workflow with a Transition to the start of the workflow, but this of course didn't work and gave the aformentioned error. This bug is very annoying and unfriendly towards new users, especially when I have to browse forum after forum to find out other people have the same issue as I have.

Like # people like this

It is annoying, but it's a minor bug, with a work-around and it only affects a small handful of users.  So it's a low priority for Atlassian.

Plus, it might be going away if the latest direction for automation is followed up in full.

Like # people like this

> only affects a small handful of users


you mean like anyone ever wanting to change the default diagram?

Like # people like this

No, we're not talking about that (and that isn't a problem anyway), it's the "can't add transition in draft unless there's one there already" problem.  

Like Simon Boda likes this

Yup, this very error happened to me when I tried to add a new transition to a default diagram where all states are like

[ State ] <--- [ All ]

I had to make a copy of that diagram, make the changes and do a migration. That's why I found this thread and why I replied in a first place.

So could there be any other reason for the error occuring to me? Because if not, this error can affect more than _small handful_ of users, right?

Like # people like this

Nope, no other reason.  It's a design flaw.

It only affects administrators, and only those who have inherited poorly designed workflows built by inexperienced admins.  That's probably less than a "small handful" of users to be honest, or at least should be, as the biggest mistake people make with Jira is "too many admins".

Like # people like this

I did not set up the JIRA, you are right. Yet I assume that the only

[ State ] <--- [ All ]

diagram is the most basic / default. In most small projects, it's what you need. How is it poorly designed? And why judging the design matters if it is a bug?

Like # people like this

It's poorly designed because the design creates this problem.

'Poorly Designed' workflow editor... or workflow

Our workflow as designed to allow teams to create their own workflows using 'drop and drag' on their Agile board.  Every status only has an inbound 'All' transition.  No mention anywhere of this restriction/bug until its too late.

Ie - some teams want to work only with 'ToDo' and 'Done' then they can. And the same flexibility for teams that want to work with a waterfall like SDLC, and they can do that without needing any assistance from a JIRA admin

So how can I fix this without releasing a new workflow that will touch 400k issues and throw our dev stats into the can?

Like # people like this

You don't - please see the conversation above!

Like Richard Lucas likes this

Thanks Nic,

Its bit of a bind (or other words that begin with 'b') to hit this obstacle as we have painted ourselves into a corner with our management reporting that is based on last update date...  doh!

Any idea if this has been fixed in newer versions (7.13 or 8) of JIRA?

Anyway, with your excellent ScriptRunner, we were able to come up with an even better solution to create a 'Corrections Needed' scripted field that could be used in a condition on the existing transitions.

Still broken in 8.1

@Nic Brough _Adaptavist_ You say there's a workaround. Please, PLEASE tell us of this workaround.

EDIT: nvm, I see it below, trying now...

So when I develop a workflow I need to know every reversion  state ahead of time?   I allowed many states to transition to Done, via a cancel transition.   The we realized that Canceled needed to revert back to the previous state, but ONLY the previous state and only under certain conditions.  Discovering this is not POOR design, its discovery process ex post facto.

No, you just need to make sure each status has at least one transition out when you create a new workflow.  You don't need to have the final design, just enough to be able to edit it later.

I think you have misunderstood the community.  The overwhelming majority of the community are people who work with Atlassian software.  But we're not Atlassians. 

There are, of course, Atlassians here, but I don't know if any of the Jira developers (or, more importantly, Product Owners) are particularly active.

The the moderators/community leaders are not developing Jira, we're working with it.  And trying to explain why it is like it is, and trying to help people deal with flaws like this one.

Our moderators and community leaders spend time trying to help.  Not fixing code problems, because we can't - we're not buildng it.

Like # people like this

Or read what has already been said and stop looking like a troll?  (a new account, just to complain about something that only affects inexperienced admins and has a simple fix?  Really?)

What's the fix as of 2020? 

It has not changed, my original answer still says what you need to do.

Oh, ok. Do we have some Jira ticket from Atlassian addressing this bug?

Like Tomislav Sulc likes this

Not sure if it's helpful to anyone else, but when I face this issue it's usually limited to me adding/editing transitions between specific status on the workflow - not all give me this error.

I can usually just create a transition for any status temporarily back to itself, save this, and I don't get the "You cannot perform this operation on a draft workflow."

Once that is done, I'm able to click on that transition then drag and drop it's endpoints to the correct statuses I was originally trying to link. No need to go through the pain of copying workflows and editing those. 

As I say, seems to work for me every time. YYMV of course

EDIT: should have gone back and tested this before commenting from memory. Tried recreating this and found it WILL prevent me from publishing the draft sometimes. So issue remains...

Like Marcin Kwiecien likes this

Yeah this is not minor. None of the work-arounds work because apparently the transition I'm trying to do is not allowed for some unknown reason. The fact that it gives no actual reason is infuriating. 

The workaround works fine - make a copy, add the transition in there, migrate over to it.

Like Amir Katz _Outseer_ likes this

It appears this was fixed for Jira Server:

But if you're on Cloud, like we are, then you're out of luck (even though the Cloud issue has more votes and watchers than the Server issue!):

Like Amir Katz _Outseer_ likes this

The way I got this to work on Cloud was to reuse an existing transition.

As for all the comments about 'badly designed workflows' - I'm using a default workflow from Jira and just adding to it..

Like Vince likes this

This is making the life harder to all admins of Jira out there. Atlassian can not just simply say this is a flaw in design and don't even plan to fix it. The workaround works but as per its name is a workaround, so we need to get the permanently fix.

We are in 2021 and software services are supposed to automate and make life much easier to both developers, PO, Scrum master and the whole community that are using this services.

Remember that this does not affect developers, scrum masters, po or most other users.  It only affects Jira administrators.  And only those who have built a workflow without this flaw in mind, or inherited them

@Nic Brough _Adaptavist_ I reread this thread (for the 11th time) and noticed that you said this a while back: "Plus, it might be going away if the latest direction for automation is followed up in full."

What exactly did you mean by that and is there any chance this already happened or is in progress?

To Atlassian: If you are not going to fix this right away, at least, please make that message clear, admit that this is currently a bug and point to a clearly written step to get around it - like editing it in disabled mode.  The lengthy information on the page that you point to really isn't very helpful either. We need good user experience, we all know things will have bugs especially this is a coding tool anyway, so no coverups, be transparent and be helpful.

This is just silly.  And everyone saying "this is awesome!" for a solution to clone a workflow in order to achieve this basic functionality should rethink what they wrote. "This" is not awesome, any "workaround" sucks. We should just be able to edit it right inside the draft  and that's it.

<sigh>  No one is saying "this is awesome", everyone agrees this could be better.  Maybe you should try reading the conversation properly?

I read it properly enough. People are not happy, I get it.  But they are not unhappy enough for me, sorry, it's just me. "Awesome" and "workaround" shouldn't even be in the same sentence when it comes to this poor functionality.

Like Fay Strickland likes this

The word "awesome" was used to say "thank you for suggesting a workaround", by one person, not "everyone". 

I was exaggerating. Sorry, I just get triggered every time I hear about this issue not being resolved properly. Obviously, that person is not at fault for thanking for a workaround and the person who provided the workaround IS awesome. 

I know, it annoys me too, it's a silly flaw.

There's a longer thread somewhere else on the same subject, with an explanation from an Atlassian which is a bit sketchy about how the mistake was made, but a lot of detail about why it's not going to be fixed.

Like Marcin Kwiecien likes this

We got our deliverables regardless of what Atlassian dictates. The awesome part is that with the help of others, we got out of this bind. We did not have to waste as much time and got it fixed, and we can move on.

Awefulness is that JIRA is a product to help us do the dev workflow thing. That's the core of it, and that very core of it does not work, and nothing is being done or taking super long time. The company that promotes Agile is not moving in that agile direction...

@Nic Brough _Adaptavist_As a Community Leader, can you provide a link to the "Official" long description on why this is not going to be fixed?   Is there an "Official" thread on this issue? 

I ask because in the community there seems to be a lot of "that's the way it is , deal with it," or "if you had experienced and well trained Workflow developers this wouldn't be an issue"   comments made by people that are in the know and these seem very condescending to those of us that have to work with this product every day without dedicated staff that knows all of these work-arounds.

Like # people like this

See the conversation above.

There is a workaround. Create a copy of your workflow in global ISSUE menu

Make necessary changes 

Switch workflow in your project to the new one

remove the old one to not create a mess of workflows in Jira)

This is awesome suggestion, Katerina!!

Hello, 2021. Still an issue. Trying to add a transition from one status to another and I can't. 

Please see the conversation above about how to work around it, and about why it's not been fixed.

If you are lazy and can't be bothered duplicating the scheme/workflow. You can instead tick "Allow all statuses to transition to this one" on a status that has outgoing transitions. Not quite the same, but if you are simply creating a way to get out of a cancelled or completed status it works well.

Can someone please help me on how to work around the error message: "You cannot perform this operation on a draft workflow." 

1) I created a copy of a screen scheme

2) I created a copy of the workflow 

3) I edited the workflow copy to add a "backlog" transition from to-do status to itself.

Result: I am still seeing the error message.

Aim: I ultimately want the ability to move issues to the backlog when I create them.


Please make sure the workflow you are editing is INACTIVE.

This saved me from making any workflow copies:

  1. Go to Settings > Issues > Workflow schemes
  2. Remove the workflow from the scheme to make it INACTIVE
  3. Edit INACTIVE workflow
  4. Go back to the workflow scheme and bind the workflow with Add Workflow

This is annoying. 
What I've done is start to use Workflow Schemes at project levels, even if they're all just joining to one "Standard Workflow" scheme that points to a single "Standard Workflow" workflow. 

That way if i need to make a new copy of "standard workflow(3)" so i can tinker with transitions, I can change it at the scheme level and update all projects simultaneously. 

Come on, just replacing an old test tool that were not covering our needs and fell over this shitty problem. Dont have time to bother with work arounds, all resolved issues will have done resolution set automatically by use of post function until you fix this.

Except from that this tool seems awesome!

Not an answer but a comment:

I'm in the evaluation process for Atlassian products and encountered this issue.

This is definitely a big -, not only as a serious flaw but also the response that a workaround is available is too lazy. The feedback on the error is also terrible:

It took me way too long before even considering that something so trivial could be a bug that needs a workaround.

Overall I'm still impressed with Jira, and competing products have their own bugs, so this won't be the dealbreaker, just a considerable negative point.

I also facing same issue in JIRA really its Kill my Mind

Due to this issue I am considering stacking shelves in the local supermarket! 

Comments for this post are closed

Community moderators have prevented the ability to post new answers.

Post a new question