- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
yesterday
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:
| Open | 1 |
| Known Error | 2 |
| Pending Change | 3 |
| Closed / Resolved | 4 |
Customized State Model
The instance I am reviewing uses the following values instead:
| 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
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?
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?
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?
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.
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
yesterday
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 as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
yesterday
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.