How to get back to out of box for Incident State and On Hold Reason

[Laurie Marlowe1]

How to get back to out of box for Incident State and On Hold Reason

First, I tried to find "revert to out of box" in upgrade history for the incident state and incident on hold reason, but could not find where these changes were skipped during upgrade.

We want to revert the incident state field to out of box selections and use the On Hold Reason field. I know I can manually change the state field choices and manually create the on hold reason field to match out of box, but I really want to revert and use system fields, not custom fields. I tried to XML the "hold_reason" field from my developer instance to our sandbox (westarqa) instance, since our incident table does not have that field. The element was added to our dictionary, but it did not add the column label for the entry. The column label field was blank. I tried to enter the correct label, but after saving, the column label field was blank again.

These are the steps I was following to try to achieve reverting:
1. Update the dictionary with the hold_reason element by XMLing from developer instance to sandbox instance
2. Set the On Hold Reason field for Incidents with state values set to Awaiting User, Awaiting Vendor, etc., to the correct On Hold Reason.
3. Update the dictionary with the state element by XMLing from developer instance to sandbox instance
4. Set the incident state field for Incidents with On Hold Reasons to "On Hold"

[Laurie Marlowe1]

Update...Thank you Allen, but that did not work.  I opened a ticket with SN, but they are still trying to figure it out.

[PerV]

I am in a similar situation, and I also failed when trying to xml the field from one instance to another. However, with the use of the great utility "Add to update set" I managed to transfer all necessary records from a PDI to my company sandbox instance. I got all things correct except the UI policy to show/hide the On hold reason field, I had to update that manually.

However, my main problem still exist: How to revert Problem management application to OOB Kingston...

BRG /Per

[pratiksha5]

Did you find the solution for it?

[Laurie Marlowe1]

We decided to stick with the customized configuration.  I'll bet you could XML out/in the On Hold state and On Hold Reason for incident from a developer's instance.  Before you do that though, you need to determine how to update historical incident records to get the On Hold Reason correct.  Maybe something like this:

1.  XML out/in the On Hold Reason field.

2.  Write a background script to populate the On Hold Reason based on the Incident state.

3.  XML out/in the On Hold state selection into the state field.

4.  Write a background script to update all old on hold records to the new On Hold state.  

Thanks,

Laurie