Directionality of CMDB relationships

[Paul Coste2]

Hello!   First question as a member of the community.   Been a couple years since my last job using ServiceNow, and I am back.   My question goes back to prior experience with CMDB relationships, so please forgive me if it is off-base as I am a bit rusty.  

My understanding is that all relationships are directional by definition (there is a source and a target, parent and child) and that they have implicit converse relationships (parent to child always has a converse relationship from child to parent, such as Connected To : Connected By).   However, in other tools where relationships are created, this is only one type of relationship.   Other types of relationships include:

• No implicit converse relationship- Main use case would be a "following" type of relationship.   The follower has a relationship to the object being followed, but the object being followed has no formal relationship to the follower.   Not sure what specific use cases there would be in a CMDB for this.
• Non-directional relationship, or identical converse relationship- Two objects are connected by a relationship that always applies the same in both directions.   (This is like a "connection" or a "friend" in social networks.   If person A is a friend of person B, then person B is also a friend of person A.)   In other words, a peer-to-peer relationship.   This type of relationship would be useful in situations where there is no clear criteria to determine which is the parent/source and which is the child/target.   This is useful in certain queries where you do need to refer to the relationship but don't care which direction it goes, so you do not have to query for both possibilities.

Does ServiceNow support either of these scenarios?   Have others found the need for this over the years and how have you accomplished it?

Thanks!

[Mark Stanger · Accepted solution]

Your assumption about parent-child is correct.   I think the thing to remember is that the relationships you're defining in this case are used to determine impact relationships as displayed in a BSM map.   You can certainly define other types of relationships using standard reference fields in SN, but the CI relationships in the BSM map are all parent/child because that's the way that the impact relationships flow.