We're reclaiming inactive PDIs to keep them available for active builders. Learn what's changing, who's affected, and how to protect your work. Read More

Problem management

shivanib56
Tera Contributor

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:

 

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
Open1
Known Error2
Pending Change3
Closed / Resolved4

Customized State Model

The instance I am reviewing uses the following values instead:

State Value
New101
Assess102
Root Cause Analysis103
Fix in Progress104
Resolved106
Closed107

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.

1 ACCEPTED SOLUTION

pavani_paluri
Kilo Sage

Hi @shivanib56 ,

 

Based on your testing, this is expected behavior.

The OOTB ServiceNow Problem Business Rules are typically designed around the standard Problem states. When those states are replaced with custom values (like 101-107), the OOTB rules may no longer recognize when a Problem is resolved or closed.

 

In your case:

OOTB rules appear to be looking for state = 4 (Closed/Resolved).
Your custom lifecycle uses 106 = Resolved and 107 = Closed.
As a result, the OOTB synchronization with related Incidents is not being triggered.
Your custom Business Rules work because they are checking the correct state values.


My recommendation
Do not modify the SNC/OOTB Business Rules.

If the custom Problem lifecycle is a business requirement, create custom Business Rules or Flows to handle Incident synchronization based on states 106 and 107.
Document this as a known impact of the customized state model.
Reverting to the OOTB state model would provide the best upgrade compatibility, but it may not be practical if the business has already adopted the custom lifecycle.

 

Answers to your questions

Is this expected?

Yes. OOTB rules often depend on the standard Problem state values.

Can custom states work with OOTB synchronization?

Not automatically. Additional customization is usually required.

What is the recommended approach?

Keep OOTB rules untouched and build custom logic for the custom states.

Should we modify OOTB rules?

No. Creating custom Business Rules is the safer and more upgrade-friendly approach.

 

Mark it helpful if this helps you to understand. Accept solution if this give you the answer you're looking for
Kind Regards,
Pavani P

View solution in original post

1 REPLY 1

pavani_paluri
Kilo Sage

Hi @shivanib56 ,

 

Based on your testing, this is expected behavior.

The OOTB ServiceNow Problem Business Rules are typically designed around the standard Problem states. When those states are replaced with custom values (like 101-107), the OOTB rules may no longer recognize when a Problem is resolved or closed.

 

In your case:

OOTB rules appear to be looking for state = 4 (Closed/Resolved).
Your custom lifecycle uses 106 = Resolved and 107 = Closed.
As a result, the OOTB synchronization with related Incidents is not being triggered.
Your custom Business Rules work because they are checking the correct state values.


My recommendation
Do not modify the SNC/OOTB Business Rules.

If the custom Problem lifecycle is a business requirement, create custom Business Rules or Flows to handle Incident synchronization based on states 106 and 107.
Document this as a known impact of the customized state model.
Reverting to the OOTB state model would provide the best upgrade compatibility, but it may not be practical if the business has already adopted the custom lifecycle.

 

Answers to your questions

Is this expected?

Yes. OOTB rules often depend on the standard Problem state values.

Can custom states work with OOTB synchronization?

Not automatically. Additional customization is usually required.

What is the recommended approach?

Keep OOTB rules untouched and build custom logic for the custom states.

Should we modify OOTB rules?

No. Creating custom Business Rules is the safer and more upgrade-friendly approach.

 

Mark it helpful if this helps you to understand. Accept solution if this give you the answer you're looking for
Kind Regards,
Pavani P