Customizing the CI Relationship Builder

[Paul Coste2]

When creating new relationships I would like to enforce users to use the Suggested Relationships only, unless they have an admin role.   However, there are many ways in which they can create relationships that go outside of the suggested ones.   The relationship slushbucket does have the ability to display only the Suggested Relationships for the base class when defining new relationships, but by modifying the Filter they can create a relationship to any CI class, whether or not it makes sense to do so.

For example, let's say I have one suggested relationship for base class Application, which states that Application Runs on Server (and a converse that Server Runs Application). I create a new relationship from an Application CI called MyApp, it will show me only the Runs On option. Then when I select Runs On, it will use a filter that shows all instances of Server.   Good so far.   I know the name of the server is MyOffice, so I search the list for MyHome and don't find it.   Assuming the filter must be wrong, I remove the clause that says "Class is Server" and rerun the filter.   I now find a CI called MyOffice showing in the list, and complete creating the relationship, without realizing that the class of this CI is also Application.   As a result, I was allowed to create a relationship that does not match the Suggested Relationship rules.

The two approaches I have considered are:

1. Modifying the relationship slushbucket so that the filter is hidden from view.   As far as I can tell, this is not possible.   I have looked at the Jelly code and logic for the display of the filter is not something that is exposed.

2. Create a business rule that validates whether the relationship being created meets the Suggested Relationship criteria, and blocking the creation of the relationship unless the have an admin role.

Has anyone looked into validating relationships against suggested relationships to see if they comply?

Thank you!

[vineethnair]

Were you able to solve this ?

[Paul Coste2]

No not yet.  I have not been able to get around to this, but it has come up more recently so I would be interested to know if anyone else has.  I did attempt to edit the legacy relationship editor but with no luck, because the elements in question could not be modified.  I entered HI tickets for this but confirmed that there was no way they could be edited. 

In a subsequent release of ServiceNow, they added a new UI element to replace the Relationship Editor.  Some of the capabilities of the newer editor are nicer, and some actually make the problem worse.  So we cannot use the new Relationship Editor in the UI unless we have something to ensure that the Relationships are created correctly. 

We would like to make more significant business logic based on the Relationship Types so that they provide more than just semantics about the CI relationship.  To do that we also need to make sure that users are able to intuitively create the right types of relationships in the right directions on the right CIs.  Given the multiple methods to add and modify relationships in different UIs, and the inconsistent ways in which each method validates the relationships, I am leaning toward creating a Business Rule that can be used to create consistent validation on all CI relationships regardless of how they are created.

[Paul Coste2]

Not yet. 

As for option 1, the original Jelly code was deprecated as the "Legacy Relations Formatter" and has been replaced with a new widget.  It's snazzier looking, uses the newer UI, but in terms of number of clicks it is actually less usable than the original.  (Try adding a bunch of relationships at once.)  We haven't moved to it yet because it just isn't as usable in many ways, even though the display is nicer.

As for option 2, this seems like it is doable, but hasn't reached the top of our priorities yet.  It seems relatively doable.  Since the relationship suggestions are validated against CI Classes, which can be inherited, you'd need to use one of the Table APIs to write this rule, and that's the part that could make it get messy, since you can't just do simple Glide queries to match the Relationship Type, Parent.Class, and Child.Class against each Suggested Relationships looking for a match -- for the Parent.Class and Child.Class, you'd need to consult the Table API to make sure that the Classes are valid matches or extensions of each Relationship Suggestion.  If anyone tries this or has tried it I would be interested to know how it worked for you.

Another factor that has made me hold off on doing option 2 this is that in the meantime ServiceNow has introduced the CMDB Dashboard which calculates Relationship "compliance"; this tells you which relationships don't match one of your Suggested Relationships.  There are a host of other questions around how this was implemented which I will post elsewhere, but basically this fact alone suggests that perhaps a better approach to validating the Relationships in many cases would be through the process of evaluating data rather than writing strict business rules.  This can be a better strategy for configuration management, as this allows more evaluation of actual usage of the CMDB which can be enlightening, turning up use cases that may not otherwise have been considered when defining business rules, and then allows Remediation tasks to be created to address any configuration discrepancies.

[Paul Coste2]

I am now leaning toward a third option which is using Remediations.  However, the business rule seems relatively doable.  Since the relationship suggestions are validated against CI Classes, which can be inherited, you'd need to use one of the Table APIs to write this rule, and that's the part that could make it get messy, since you can't just do simple Glide queries to match the Relationship Type, Parent.Class, and Child.Class against each Suggested Relationships looking for a match -- for the Parent.Class and Child.Class, you'd need to consult the Table API to make sure that the Classes are valid matches or extensions of each Relationship Suggestion.  If anyone tries this or has tried it I would be interested to know how it worked for you.

In the meantime ServiceNow has introduced the CMDB Dashboard which calculates Relationship "compliance"; this tells you which relationships don't match one of your Suggested Relationships, and allows you to create CMDB Remediations.  There are a host of other questions around how this was implemented which I will post elsewhere, but basically this fact alone suggests that perhaps a better approach to validating the Relationships in many cases would be through the process of evaluating data rather than writing strict business rules.  This can be a better strategy for configuration management, as this allows more evaluation of actual usage of the CMDB which can be enlightening, turning up use cases that may not otherwise have been considered when defining business rules, and then allows Remediation tasks to be created to address any configuration discrepancies.