A related list on a form serves the purpose of providing additional information related to the form record and gives a quick overview of how the other records would be affected if something is modified in the current form record.
Also, it provides an ease of creating new records or adding existing records, based on the permissions available to user, from the child table for the parent one.
For example: the screenshot below gives a single pane view of what all different tables a user may be related to in ServiceNow:
Here based on the related lists, you can easily tell that this user is an end user since there is no role associated with the user, has a single group membership and has an asset assigned.
Types of Related Lists:
At first glance, these all related lists seem similar but behind the scenes there are multiple things working to provide you with what is termed collectively as related lists.
Following are the types of related lists that are available:
- Reference field association (for lack of better term)
- Many to Many Definitions
- Sys collections
- Relationships
Reference field associations
This is the most common and easily available type of related list in the system. This type of related list is available when a record is available on another record form via a reference fieldFor example, a user record is available on asset form as a part of assigned to reference field. This will provide a related list for that association as seen in the screenshot below:
Note: . This is a one to many type of relationship.
Using this related list you can assign an multiple assets to a single user but not the other way round.
Many to Many Definitions (sys_m2m)
Many to Many Definition tables allow a list to point to multiple related entries rather than one. For example, A knowledge base article can be related to multiple Configuration items and vice-versa is also true. This scenario can not be covered by the related list mentioned above so we use a many to many definitions type relationship. In the screenshot below the Configuration Item CAROL2-IBM is related to multiple knowledge articles and one of the knowledge articles (KB0000033) is also associated to multiple Configuration Items.
Sys Collections (sys_collection)
Some many-to-many relationships are defined by default.
To reference many-to-many relationships that are available in the base system, administrators can enter sys_collection.list in the navigation filter.
Note: Only use this table to view many-to-many relationships in the base system. To create a new relationship, always use the Many-to-Many Definitions table.
Relationships (sys_relationship)
This is the one which inspired me to write this all down and share. This is something that was hiding in plain sight and I only stumbled upon it because of an improvement in the current process.
We had a scenario where we had to show all the outages related to an incident alert. That would include all the outages directly associated to the source incident record, all the outages related to the child incidents of the source incident (mentioned above), any planned outage associated with the impacted configuration items.
Doing this via many to many definitions is possible but it is manual and time consuming. This is where the sys_relationship comes into play. This tables helps create a relationship between the records you want (in my case outages) and the record you’re at (incident alert in my case), even though they may not be directly connected in the system.
An example for a relationship is in below screenshot, this provides the problems related to an incident alert based on the source incident.
Hi Varun,
Is there a way we could find out a particular table which is setup as a related list on different tables.
For example, the Approvers related list on Change Request is also setup on the Requested Items. I need to find out all tables where "Approvers" is configured as a related list.
And, also to understand your article better, could you please confirm what type of Related List "Approvers" related list is (out of the 5 you've documented above)?
If I understand your question correctly & the diagram depicts your scenario, then the only place you need to check is Table 1. So in your case, Approvers is the Table 1.
we can configure the related list tables which are available to users in the related list query. The related list query is only available in List v3.
The administrator can add a system property for any table and specify which related tables to exclude for everyone from the choice list.
