Updating closed Change tickets.

[leonbrowning-pa]

Hi,

In our existing process and ITSM tool (Remedy), we often have cause to revisit a closed Change ticket when it has been found to have caused issues (it often either takes time for those issues to present themselves or for people to make the association with the change as the cause).

The Change Manager group has the ability to add updates & edit pretty much every aspect of a closed Change ticket and do this to change the outcome classification (ie usually away from "Success" to one of our other "Failed" cateogories).

We are in the process of implementing Service Now, and our supplier is maintaining that for us to be able to edit closed changes, customisation is required that poses a threat to future upgrades - does anyone know if this is true?

I would be very interested to hear what other Service Now Change Managers do about re-classifying & updating closed Changes.

Many thanks

Leon

[Anurag Tripathi]

Hi Leon,

If I understand you correctly then you need to modify some fields on old closed tickets without triggering any other functionality of the ticket.

This is very much possible in Service now

You can write an on demand Scheduled job to run the script (reusable)

Creating a Scheduled Job - ServiceNow Wiki

OR

You can do it with background Scripts.

Useful User Scripts - ServiceNow Wiki

Whatever you use , use these lines in the code, will be useful

gr.setWorkflow(false); //Do not run business rules

gr.autoSysFields(false); //Do not update system fields

gr.setForceUpdate(true); //Force the update

gr.setLimit(100); //if the data to b updated it is huge then you can break it in batches with this

[Kalaiarasan Pus]

These sort of changes will not cause any issues. Issues with upgrades are more related to editing items that came with out of the box settings. Ex: macros and UI pages.

In your case, you can add Access control to change table and allow your change manager (or any similar person) to edit the closed tickets.

More about access control

http://wiki.servicenow.com/index.php?title=Using_Access_Control_Rules

[Uncle Rob]

While "customization" is required, this kind of thing uses the standard building blocks ServiceNow is intending for its owners to utilize.

I'd ask your vendor what, specifically, jeopardizes your upgrade, and how.   If they can't articulate that, its time for a new vendor.

[d_cammack]

Hello Leon,

It would be interesting to know just how much customization would be needed that would cause issues with future upgrades.   For instance, the fields that are made read-only on a change request may be done on a single UI policy (which may not be an out-of-box setup) which you can copy and update while making the original copy inactive.   You can then create a role for the change manager and have the ui policy work on any user that does not have this role.  

Of course, you will want to think about any notifications or processes that may be kicked off when certain fields are changed, just as Anurag mentioned above.   For instance, if the Change Manager adds work notes when the ticket is closed, the notification would not be sent if the notifications have a condition of 'active = true'.  

Best regards,

David