nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

You cannot perform this operation on a draft workflow

itay keller_wv2a22

Hi.

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.

Thanks

Accepted answers

All comments

Christian Czaia [Decadis AG]

Hi,

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:

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

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

Daniel Sedlacek2

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?

Daniel Sedlacek2

Why?

Why such arbitrary limitation?

Why is the error message so unhelpful?

Marc Turner

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.

unknown

Symptoms

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

Cause

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.

Resolution

There are two different options:

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

Source: https://confluence.atlassian.com/jirakb/cannot-add-transitions-or-delete-steps-in-draft-workflows-203392961.html

Enrico Foschi

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.

Vinny Kawano

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.

jbburf

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.

David Holman_2g7dk8

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

Fredrik Wallgren

This horrible bug is still present, please fix it.

Max Sikström

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...

Marc Moroz

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.

Nic Brough -Adaptavist-

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

David Holman_2g7dk8

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

Brian Pohuski

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

Bill H

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.

Alan Martinez

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.

Clive Brett_o365ec

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.

unknown

Still has the bug?

Nic Brough -Adaptavist-

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.

Stacy Story

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.

Nic Brough -Adaptavist-

>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?

Brendon Miszka_85qitj

This is terrible, please fix it.

Victor Vucicevich

Unacceptable that this is still a bug.

Nic Brough -Adaptavist-

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.

Stacy Story

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

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.

Andy Heinzer

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 https://jira.atlassian.com/browse/JRACLOUD-68734
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.

TLDR:

Please follow the steps in the KB https://confluence.atlassian.com/jirakb/cannot-add-transitions-or-delete-steps-in-draft-workflows-203392961.html
It's not a bug, it's a feature
Please vote/watch JRACLOUD-68734 to help us improve/update our documentation.

Cheers,

Andy

Bill H

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.

Andy Heinzer

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.

James Ryan_c9l6d7

@Andy 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?

Brendon Miszka_85qitj

I agree with @Matthew Thurmaier
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.

Mad Octopus

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.

Bennie L. Callies, Jr.

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.

Matt Nelson_6t8a8t

Agreed, I added a step Not a Bug, put a transition to it, but forgot to transition out of it. Now I face the pain of fixing it by copying my workflow and editing the copy and reallocating the projects to the new copy, just to add a transition.

Ishita Datta

The issue wasnt really sorted with any of the solutions on this thread. Any one tried anything else?

If some one from JIRA is here, guys please please dont torture users like this. JIRA is a very very complicated product already, which needs people to go through trainings and videos and the whole learning curve. To top that u guys are making this product like a never ending maze of confusing features.

Sincere request, please see if going back to drawing board is an option.

Nic Brough -Adaptavist-

Please see Christian's answer from Jul 09, 2015

See also Andrew Heinzer's answer on why it's not an easy fix, and understand the point that although it would be nice to have it fixed, this is a low priority because it only affects admins, and only causes a few extra steps in a process for us.

Brian Pohuski

Hey Nic,

Just thinking outside the box here... is there a way the workaround could be accomplished via 2 scripts?

I'm just thinking script 1 would be pre-changes (to automate duplicating & renaming the workflow), and script 2 would be post-workflow edits (to save, activate in the scheme, and delete the old workflow).

Obviously a core change would be best, but, I empathize on the prioritization. A duct tape solution is better than nothing in the meantime! I am just not knowledgable enough on traversing workflows with scripting. I guess we would have to fit the multi-step process of converting any statuses as well. Anyone here know?

Nic Brough -Adaptavist-

Very good idea. I especially like the split into pre/post, so that you would have a script that an admin runs to put themselves in a place where they can edit, then a second to do all the work of applying it. There is a difficulty in the second script, in that Jira does loads of checks on "activate" and may start asking questions if the admin has done something to status on top of adding transitions. But scripts would help simplify this a bit.

Brian Pohuski

Ethan, any chance you could add those suggestions within the comments on issue JRACLOUD-68734 and upvote? Clarity on the error message was the original intention of that issue. Constructive dialog is important.

Brendon Miszka_85qitj

@Brian Pohuski I've up-voted your error message suggestion now as well.

Christopher Watson_ixkb6p

On a more helpful note, for anyone else' reference, I discovered a possible workaround where you can at least add a status (if that's what you were after) and set it to 'Allow all statuses to transition to this one'. This will allow you to manually set it to this new status and publish.

Not ideal, but hope that helps someone out.

David Hazeel

Thank you for putting this here - it saved me a lot of time.

Jared Lindquist

ugh

1. Set custom workflow up for the service desk

2. service desk has been operating for a while 200+ resolved tickets

3. go to add a report about resolutions

4. can't because the status may be resolved but the "resolution" isn't set to resolved

5. rolls eyes

6. create a post function to set the resolution on all my transitions

7. realize this isn't a retroactive update

8. find how to bulk update here:

https://confluence.atlassian.com/jirakb/howto-bulk-edit-resolution-321857142.html

9. oh wait, can't do that because can't edit draft workflow, even though that's what it says to do.

Start by Editing your existing Workflow.

10. ಠ_ಠ

Farid Bonawiede

I thought the "draft" feature was intended for this use case. Thanks for the workaround! And thank you Atlassian, for nothing...

Sana Khan_3fzlcu

Can we please expedite the developer/designer round up process, its urgently required that these people are in that aforementioned room.

Kasia Bobinski

Trying to use the workaround for this problem suggested by users in this community but can't make it work.

Can someone help please? Steps to recreate where I get stuck:

Create a brand-new project.

Go to workflows tab.

Add a status.

Click on status and Add a transition.

Click 'Add'

Receive an error message 'You cannot perform this operation on a draft workflow. More Information'

Whenever I try and create a copy in order to make any changes I need to edit it. Therefore creating a draft. Going round in circles.

Nic Brough -Adaptavist-

I think you should take a look at how prioritisation works. This problem affects two types of people - inexperienced admins who have not seen it before, and experienced admins who are cleaning up after others.

On top of "only a few people affected", there is a manual fix. Less than ideal, it's a bit slow for the few affected, but it works, there's no damage done to data, but it's easy to fix.

That autmatically makes the problem not at all "urgent" - a fraction of users are affected, the problem is easily fixed, and even easier to prevent. The only real problems are that 1) it's a bit silly that we have to do it and 2) it takes a bit longer than we should have to take to fix it.

Nic Brough -Adaptavist-

I can see why the conversations above get complicated and unhelpful.

I think you are very very close to fixing it, but missing how to extract the fix from our conversations (because we barely mention it, mostly we're talking about how stupid a design flaw it is and why it's hard for Atlassian to fix it and actually how few people it affects!)

There is something missing from your description though. You say "create project" then "go to workflows tab", but you do not say what you selected for a workflow or how.

I could wait for answer to that, but I would prefer to get you past the problem.

Let's say we stick with the new project you just created. Go to the workflows tab and take note of the name of the workflow you have. Now go to Admin -> workflows and find that workflow. Copy it, and edit the copy, adding the transitions you need.

Then, go back to the workflow scheme and replace the old workflow with the edited one. You might be asked to migrate if there are things Jira can't handle, but it will ask the right questions and give you the option to cancel changes.

Pankaj Verma_ajbjow

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.

Pankaj Verma_ajbjow

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)

But, 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.

Kasia Bobinski

Thanks Pankaj.

The step I was missing is going to the Inactive section and editing from there.

I found my copy of workflow in the inactive workflows section and was able to edit that. I was finally able to add a transition for the first time ever. YEY!

A bit annoying though how you need to apply the workflow each time before you can test it out on your columns and see if it works how you imagined it to work. Ideally you could see the columns in situ and be able to play around with the Jira tickets, adjust that workflow and add/remove transitions to make sure it works.

Anyhow, using this approach every time you want to make a change to the workflow you need to create a copy. I am ending up with lots of copies. Is there any way to delete them? I did go to Active workflows and edit and delete draft. But the workflow stays displayed on the workflows page. It is not an active workflow as I did overridden it.

Thank you so much for your help.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

jira-administration