Hi @abhijeetpaw ,
Yes there are upstream and down stream relations for service instance you can see them by following steps:
1. Go to all navigator search for the CI Class Manager
2. Search for the Service instance there
3. After choosing service instance table , if you click on the All relationships you can see something as shown below
On this pane, you can see all the existing relationships along with the suggested relationships (which are provided by ServiceNow). Since no relationships have been explicitly defined yet, you may only see the suggested ones.
In the image, there is a filter option available. By clicking on it, you can filter the relationships based on Inbound and Outbound.
If you’re unsure about the difference between inbound and outbound relationships, you can refer to the following explanation ,it should help clarify things.
It’s important to understand that these terms only describe how records are related in the CMDB, not how impact is automatically determined. If you look at the cmdb_rel_ci table, each relationship is stored with a parent CI and a child CI. From the context of any given CI, related records are identified purely based on how that relationship is defined.
When we start talking about what affects what, it’s important to remember that it can work in both directions.
Imagine you have a CMDB structured like this:
Email Service
Mail Application
Email Database
If the Email Database goes down, an Incident would be opened against it. The Mail Application would then show that there is an Incident on one of its related components. Since the Mail Application is linked under the Email Service, the same Incident would also appear as impacting the Email Service. In this case, the Email Service cannot be considered fully operational while the database is unavailable.
Now consider a different scenario. If the Email Service itself is unavailable, then the Mail Application and Email Database are also affected. However, there’s no need to create separate Incidents for the application and database, because the root issue is already known at the service level.
At the same time, not every issue at the service level impacts all underlying components. For example, if the Email Service has a configuration or policy-related issue that doesn’t affect the Mail Application or the Email Database, those components may continue to function normally. In that situation, someone looking only at the Email Database wouldn’t necessarily need visibility into the Email Service issue.
And coming to your final question:
A service instance should not be directly related to infrastructure CIs as a general best practice. Instead, it should be linked to an application service, which in turn is related to the underlying infrastructure such as servers and databases. This layered approach keeps the CMDB scalable, easier to maintain, and supports clearer impact analysis.
Hope this helps you, Please do mark it as helpful . And accept the solution.
Thanks,
Vishnu.
