Ability to nest Application Services
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-11-2024 07:13 AM
I am a little confused 🙂
It is my understanding that you do not nest Application Services within themselves (i.e. Application Service - Parent with Application Service - Child).
From an Application Service Group perspective, we can easily nest them for Service Operations.
From a Service Portfolio view - we align Application Services to Service Offerings
Application Services can contain Technical Service Offerings
I am struggling with this csdm_view of Application Service and Set Relationship to Parent Application Service
If I set this relationship, on the Service Map it provides IMO an OK view of the maps but in reality the alert on shows on the impacted application service map even though I can see both maps on the view.
In SOW, I can see alerting propagate but no where can I see a depends on view.
My questions:
1) Is it a leading practice to nest Application Services (not ASGs)?
2) If so, how is this done and seen in the platform?
Application Service Depends on Application Service
Application Service sends Data to Application Service
Thanks in advance
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-13-2024 01:38 PM
Great feedback - I love the example of Exchange and DNS - I 100% agree that in your example Microsoft Exchange Prod On-Premise has a depends on relation with Prod Internal DNS Application Service.
If the Prod Internal DNS Application Service fails other Application Services I imagine in addition to Microsoft Exchange Prod On-Premise would be impacted for sure but I am struggling with the concept that Prod Internal DNS Application Service is the parent of Microsoft Exchange Prod On-Premise.
I think of Parent >Child like sharing a common DNA thread and these do Application Services do depend upon each but they are not Parent and children but maybe that's what I need to just rationalize 🙂

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-14-2024 01:02 PM - edited 04-15-2024 05:25 PM
Thanks. I hear what you are saying, and I wish the terminology could be a bit different. ServiceNow is constantly evolving! Take a look at this article and the CMDB Whisperer's response: https://www.servicenow.com/community/common-service-data-model-forum/dynamic-ci-group-and-cmdb-group...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-19-2024 10:45 PM
I'm also a bit confused by this new pattern. I understand the 'platform & application' concept, but - from what I understand of the 'service impact' code - I don't see how 'impact' would propagate from the child application service to its parent application service, which appears to be the goal of your scenario. What have I missed?

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-20-2024 04:28 PM
You haven't missed anything. Impact would not propagate.
Application Services are containers for CIs, and can have relationships between themselves. You can absolutely parse these relationships to see how they connect, and you can list the CI's within them. You can propagate operation attributes such as impact with code but they don't propagate OOTB.