'Impacted Services/CIs' related list not auto populating up on submitting the Incident
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago - last edited 3 weeks ago
How exactly 'Impacted Services/CIs' related list works on Incident form?
I have set this property to TRUE 'com.snc.incident.refresh_impacted.include_affected_cis'
I have chosen a CI which is associated with 2 Application services.
Upon submitting the INC, the 'Impacted Services/CIs' related list is empty.
Only after clicking on 'Refresh Impacted Services' UI action in context menu, 'Impacted Services/CIs' related list got populated.
Why so?
Is it expected that resolvers should manually clicking the UI action every time?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hi @Arun Kumar D,
This is by design, not a gap in your config. com.snc.incident.refresh_impacted.include_affected_cis doesn't make the refresh run automatically on submit, it only changes what gets pulled in once a refresh actually runs. With it set to true, the lookup switches from cross-referencing just the Configuration Item field through cmdb_rel_ci, to instead reading everything on the Affected CIs related list against the svc_ci_assoc table, which is why both application services on your CI would show up once refreshed. But the thing that actually triggers that lookup is still the Refresh Impacted Services context menu action, which calls the TaskUtils script include's triggerRefreshImpactedServices method. Out of the box there is no insert business rule on Incident that fires that on submit, so yes, today resolvers do need to click it.
A few things worth knowing if you want to close that gap:
- Business rule automation calling triggerRefreshImpactedServices from a rule on task_ci insert has been tried by other admins, it shows the "refresh initiated" message but often does not actually populate the list, since the record context differs from a live form submit.
- Alert-generated incidents have the exact same limitation, Impacted Services does not auto-populate there either.
- If you do build automation for it, add logging inside the script include itself, that is the fastest way to see where the async process is dropping the update.
References
- Refresh impacted services automation not working
- What is the use of 'refresh impacted services' UI action in the context menu
- When incident is created from the alert rule the impacted services are not shown automatically
Thank you,
Vikram Karety
Octigo Solutions INC
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2 weeks ago
Hi Vikram,
How the Impacted Services are populating for the first time? When the user submit the incident, it automatically populate once. How this is happening and what is triggering this?
At the same time when an incident is triggered by some alert rule then it is not setting the Impacted services. How or where is it classifying if an incident was created by a user or alert?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
It is expected out-of-the-box (OOB) behavior.
Resolvers are natively expected to click the Refresh Impacted Services UI action manually.
Refer: KB2314029 How will 'Impacted Services/CIs' populated in the Related List on the Incident Form
Resolution
The Impacted services can be refreshed using the 'Refresh Impacted Services' UI Action and there is an out-of-the-box business rule to sync business services with the Impacted services.
The name of the business rule is 'Sync BS with Impacted Services' from the Service Management Basics.
When the Impacted Services is refreshed from the UI Action, it triggers the TaskUtlis and the TaskUtilsSNC, which invokes the triggerRefreshImpactedServices function.
This function verifies the properties mentioned in the documentation and determines whether to invoke the refreshImpactedServicesFromAffectedCIs function or the refreshImpactedServices function.
If the property com.snc.incident.refresh_impacted.include_affected_cis is enabled, the function refreshImpactedServicesFromAffectedCIs from the 'CIUtils' Script Include is invoked, which fetches records from the Service Configuration Association (svc_ci_assoc) table.
This table has entries when Service Mapping is being used and has all CIs associated with a particular application service, and additionally removes the manually added Affected CIs and adds the Impacted Services.
If the property is not enabled, the function refreshImpactedServices is invoked, which queries the Impacted services from the Affected CIs and removes the manually added Services.
This function also considers the servicesAffectedByCI, i.e., records downstream of the Affected CI, by adding the services associated by service mapping.
Please refer to the script include for more information on the triggerRefreshImpactedServices function: https://<instance_name>.service-now.com/nav_to.do?uri=sys_script_include.do?sys_id=1cf5818a878010100e3dd61e36cb0b4a
Regards
Tanushree Maiti
ServiceNow Technical Architect
LinkedIn: https://www.linkedin.com/in/tanushreemaiti
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2 weeks ago
Hi Tanu,
How the Impacted Services are populating for the first time? When the user submit the incident, it automatically populate once. How this is happening and what is triggering this?