How to revert to previous workflow version

[#1]

Hi everyone.

I found out yesterday we somehow had two duplicate workflows in our environment. Not duplicate but they shared the same name (but they are many changes different) which I expect that two people signed it out at once.

I made the mistake of going in and renaming the older of the two 'backup'. In doing this I made the old one published! I can't figure out how I can go back to the other versions of this workflow and revert back to it. It won't even let me open it up to tell it to publish.

PLEASE tell me there's an easy way of opening up an older version and publishing that one instead!

[tony_fugere]

There are some recovery options, but they are best not attempted over a thread like this as they require expert eyes to make decisions based on your exact situation. Here are some rough ideas of where I would go with this, but again, I do not recommend doing this directly in production unless you have a recovery path in place (and/or do it during a slow time for your company). Be sure to try this out in QA if QA is suffering from the same issue. If QA is NOT suffering from the issue, consider cloning Production to QA in order to test before you try in production. If you don't have a QA instance, then DEV might be a good home for this, but you'll lose anything good in DEV.

1. Go to DEV, start an Update Set and select it.
2. Go to the Workflow Editor, open your workflow and make a COPY of the good workflow.
3. Publish the workflow.
4. Promote the update set to QA or the next appropriate instance.
5. If any records have already started to use the duplicate WF's, be prepared to yank it from underneath them or work with the users affected by that record to find a good recovery path to accomplish the work in the workflow.
6. Using the sys_id of the workflows, find out which one you want to keep by matching the sys_id with the good workflow you copied in step 2 in your DEV or appropriate sub-prod instance.
7. Based on that sys_id, determine which of the others from the WF_WORKFLOW table will need to be removed.
8. If you've determined to yank the WF from underneath any records in step 5, be prepared to trigger them to start the new workflow from step 4. If any field changes were important to the workflow, you may have people "start over" or start a new record altogether to ensure accuracy. If the workflow doesn't attach by an update to the record (change the state or add work notes) , then the Workflow Script Include can be used to build a background script that will attach the proper workflow.
9. Delete the workflows that have the wrong sys_id's in each environment.
10. Verify results. Fix anything manually if necessary.
11. Once you've done this in production to get production back to "golden" CLONE IMMEDIATELY to DEV. This will allow the Workflows and Versions to get back in sync on DEV so your future development work will succeed.

If you are working with an implementation partner, they should be able to help. If not, ServiceNow support (via HI incident) can assist. If I had some free time to give, I would, but I'm guessing you need something sooner rather than later (especially based on how old this post is now). I might be able to give up a free hour the week of 12/17, but I cannot make any promises.