Deleting Checked Out Workflows

jmiskey
Kilo Sage

In our DEV system, there are a handful of old workflows (Workflow Editor, NOT Flow Designer) I have checked out for various reasons.  Sometimes it is because you need to check it out to investigate it and see a "friendlier, more complete view of the details of each action.  Other times, it may be because I was just testing something.  In any event, I usually delete the recent "checked out" version, so it reverts back to the most recent published version before I do any new development work on that workflow.

 

I am experiencing something weird.  I had about 10 checked out workflows (all in the Global).  I opened them up, one-by-one, went to the Context Menu (hamburger) and clicked on "Delete" to delete the checked out version.  I was able to do this on 7 of them.  But the other 3, which still show as "checked out by me", do not give me an option to Delete them when I go to the Context Menu. 

 

Why would that be?  I am not sure why these are behaving differently.  I want to delete the current check out versions so I can start making new changes (and not pick up anything else I may have been messing around with/testing before).

 

Thanks

1 ACCEPTED SOLUTION

Hi,

There was a comment in the other thread that said the same thing...they could delete some but not all of them.

As far as deleting them, I don't think you can pick it based on date. I would check Executing Activities or Active Contexts to make sure there is nothing currently active / tied to the sys_id of what you want to delete before you delete it and I would export it to XML just in case you need it again. I would look to stay with the one that won't damage any open tickets since each workflow creates an instance tied to a record. Or run it from a fix script so you can always rollback from the delete.

View solution in original post

11 REPLIES 11

If you are on the list view there is the Workflow version column, you would include a condition where you dotwalk to the sys_id of the Workflow version to see which one it is using. Hopefully, they are relate to the one you want to keep and you do not find any related to the one you want to remove. Again, I would always export the XML before deleting or put into a fix script so you can rollback if needed. I would also suggest investigating why this happened in the first place as having multiple checked out version seems like an issue that should not be occurring.

Thank you.  This was most helpful!  The interesting thing is, the most current one is NOT active in any of the Active Workflow Contexts!  All new requests seem to be using the previous one.

 

One last question regarding this newer one that is not being used.  Is it better to just change the value of the "Published" field from "True" to "False", or should I delete it altogether?

That does seem odd. I would probably keep it and mark it as published is false and make sure the one you want it listed properly.

OK, thanks.  Yeah, it is odd. I am not really sure how that could have happened.

 

So, everything appears to be "locked" down, and I am unable to delete the record I don't want, nor can I changed the "Published" or "Active" fields on the record.  Not quite sure how to update those values or delete the record.  I supposed I could use a background or fix script, but not sure if that is a good idea.

I have run scripts in the past to change this field. Here is a posting where someone else did it as well. You just want to make sure you have the correct sys_id on the one you want to adjust and again, you have the option of rolling back if needed.

 

The situation where I had to do it was different. Where I was working on a flow and for some reason another dev had a story on the same cat item. So they checked out my flow which was not yet done, did their changes and started to move forward, but the customer had more changes for me to make. So we made my version back to the published one so I could finish my adjustments, get it approved and moved forward and then they could check out my version before making the adjustments they needed...but this was more of a case of out intake process not catching this and combining the stories instead of having it worked that the same time.