Problem managment

[shivanib56]

Hi everyone,

I'm performing an assessment of an Incident/Problem Management implementation and I'm trying to understand the impact of a customized Problem state model compared to the standard ServiceNow state model.

Current Situation

Reviewing the OOTB Problem Management functionality, I found several ServiceNow-authored Business Rules, including:

• SNC - ITIL - Resolve Related Incidents
• SNC - ITIL - Close Related
• SNC - ITIL - Update Related Incidents

These rules contain logic similar to:

JavaScript

1

current . problem _ state . changes To 4

Show more lines

which appears to assume the traditional Problem state model.

OOTB State Model

From ServiceNow documentation and OOTB references, the Problem state values appear to be:

State Value

Open	1
Known Error	2
Pending Change	3
Closed / Resolved	4

Customized State Model

The instance I am reviewing uses the following values instead:

State Value

New	101
Assess	102
Root Cause Analysis	103
Fix in Progress	104
Resolved	106
Closed	107

There is also a dictionary override that designates 107 as the closed state.

Observed Behavior

During testing:

• Activating the OOTB SNC ITIL Business Rules did not automatically resolve or close linked Incidents.
• The rules appeared to be waiting for problem_state = 4.
• The customized lifecycle uses values 106 and 107 instead.
• Creating custom Business Rules that react to the current state values (106/107) successfully resolved and closed related Incidents.

Questions

1. Is it expected that the OOTB SNC ITIL rules depend on the default Problem state values and will not function correctly when the Problem lifecycle is customized?

2. Has anyone successfully extended the Problem state model with custom values such as 101-107 while still retaining the OOTB synchronization behavior between Problems and related Incidents?

3. What would be considered the recommended ServiceNow approach in this scenario?

   • Revert to the OOTB state model?
   • Customize the OOTB rules?
   • Create separate custom Business Rules?
   • Use an extension point or another supported approach?

4. Is there any ServiceNow guidance or best practice documentation that explains how Problem Management synchronization should be handled when the Problem state model is customized?

I'm particularly interested in understanding whether this is considered an expected consequence of changing the Problem state model or whether there is a standard upgrade-safe approach for preserving OOTB functionality.

Thanks in advance for any guidance.

[Mark Manders]

OOB will always depend on OOB components/states/config. You can't expect it to automatically accept customizations. Customization means you own it. So advice will always be: go to OOB, but there must be reasons why this customization is in place. Start there. If it's not needed (anymore) they may allow you to go back to OOB. And if they insist on keeping it, your questions on how to revert back are irrelevant.