What's the best way to cancel 5000 RITM tickets + Flow Execution?

[MandyMaseyM]

Hi everyone, our catalog form is using Flow Designer instead of Workflow when creating RITM/SCTASK tickets.

Now, we have 5,000+ invalid RITM tickets that we need to cancel, along with their flow executions. I just want to ask what the best way is to cancel them.

I was thinking of using a background script, but I think it's too risky, especially since we have to do it in the PROD instance. Can you suggest a better approach? Thank you. 🙂

[GlideFather]

Hi @MandyMaseyM,

based on the role who will perform that, you can write a fix script or Update job.

 

In the update job, select the particular table, add filters how to find these 5000 records (example with short description), if not easy clustering then you can create multiple update jobs.

Then you can update selected fields - in my case it is adding a comment to inform about the auto-closure and changing state to Closed Incomplete.

Then I strongly recommend to uncheck the two fields in the left-bottom corner, because closing the RITMs might and will trigger notifications and other background actions, marking this field false will not execute it, equivalent to setWorkflow(false) in the business rules.

The Auto-updating system fields is related to the Updated and Updated by fields, whether you want to keep the value before the mass update or if you want the mass update to be reflected here. Set true/false accordingly.

What is great about this approach - it is code-less so less technical users can benefit from it and most importantly it has fallback record so you can revert the changes made buuuut for reopening RITMs wouldn't be the best scenario (closing RITMs will close REQs and it is irrevertable or brings issues).

I am almost done, what i would suggest is to check if these 5000 RITMs have some SCTASKs associated.. because RITM is closed when all its SCTASKs are closed (if any exists). If you would only update RITM and its SCTASK would be still active, this closure might not be accepted and ServiceNow would make it invalid update. Verify this with one or two records (manually) to know this before you start.

[MandyMaseyM]

Hi @GlideFather thanks for responding. I'm actually new to ServiceNow. I am not familiar with fix script and update job.

Just want to ask, will it also cancel the flow execution? And regarding the filter condition, we do have the list of 5000+ RITM tickets. It's all from different catalog forms with different Short Description so I am not sure if we can filter using the Short Description.

Can we just use the exact RITM number instead?

[GlideFather]

Hi @MandyMaseyM,

alright, then open the update job in your PDI,

available at https://developer.servicenow.com/dev.do#! 

and the filter can be done in several options, it really depends no what records you want to filter, there's no universal answer.

Example: RITMs created Last year > 1 record match conditions...it is in my PDI and I don't have many records available there...

Then for these records - do this update (below the new criteria) : 

State changed to Closed complete

Comments "This RITM was manually closed due to maintenance job."

Unchecking the 2 fields.

Continue > Select when to execute it and you are good. 

In the update job it show you preview of how many records are applicable to that change, it can be per category, short description or pretty much anything that defines the 5000+ records. For example if there was an outage you can select by creation date in combination with some other marker.

If you are unable to cluster the 5000 records, you might want to do more update jobs to cover it all.

To avoid executing the flow I explained above that it is possible by unchecking the 2 fields. If you decide to use flow or scheduled job you can add the setWorkflow(false); to the script.

Remember that RITM is ALWAYS associated with REQ and sometimes with SCTASKs.. closing SCTASKs will close RITMs and closing RITMs will close REQs. If you close a RITM that have some SCTASK the closure might be blocked due to that...