Why are there duplicate Related List items available for the Entity Type module? [OOTB]

[spacecowboy]

[OOTB] I noticed that the Related Lists for the Entity Type form contains duplicate items. These duplicate items are illustrated in the screenshot below. What purpose do these duplicate items serve? 

[Notorious BFG]

Hey HanSolo (I still maintain you shot Greedo first, regardless of what anyone else says)!

So this isn't something unique to just the GRC applications - it's something you'll see throughout various applications in the platform and once you understand how the Related List slush-bucket works, it will make a little more sense.

So when you configure Related Lists, the ListCollector (the object that is gathering up options to display in said slush-bucket) attempts to find any and all relevant related tables and display them as options.  But as you may know, there are multiple ways for tables to relate to one another and a table could be related in the following ways: 

• A single reference field resulting in a one to many relationship (think about parent child relationships, like major incident and related incidents or Attestation instance to Control)
• A many to many relationship (like users in groups, or Entities in multiple Entity Types)

Now where this gets a little tricky is when it comes to m2m relationships and how we query them.  Let's take the example at the bottom of the list collector you shared in the screenshot: Risks

The first related list has a query structure that would look something like this:

/sn_risk_risk_list.do?sysparm_query=source_list{sys_id}

The second related list has a query looking for something different:

/sn_risk_risk_list.do?sysparm_query=profile_type{sys_id}

In this case, the saved query of profile_type isn't used on this particular form (though it's used elsewhere on this table) and won't return any sensical values in relation to this record (if you think about it, it makes sense for a Risk to be able to see which Entity Types it relates to but not visa versa).  In the case of source_list - this is the exact reverse from profile_type and would yield all Risk instances that were generated as a result of, or are related to, this Entity Type.

Now, you might be saying to yourself, "Why doesn't this sort of thing happen elsewhere in the platform?" and that would be a reasonable question, and the answer is that it DOES happen elsewhere in the platform - but only in applications with relationships as varied and interwoven as they are in GRC.  You don't typically see this sort of thing in ITSM or HR but it's quite common to see when parsing through Threat Intelligence attack methods/vectors meta data or Vulnerability records like CVEs or CWEs.  If you're curious about how to leverage these kinds of queries across other tables you can learn more on docs here.

[spacecowboy]

Beckett taught me a valuable lesson the hard way, Ben 😉

Thanks for explaining the concept, Ben. I need to read more into all the answers provided by the community. But it seems this is an intended design, for which one of the two(2) related lists will most likely be NULL. It'll just need a quick experimentation to determine which one will show NULL, and that Related List will need to be omitted from the layout. 

[Dexter Parre_o · Accepted solution]

There are two fields labeled as Profile Type in the control and risk tables, both of them inherited from their parent table sn_grc_item. The first one is source_list (List type) and the other one is profile_type (Reference type). See below:

By default, the two fields are not shown in the form. Also, by default, only the source_list is populated when a control/risk is created by adding a profile type to a risk statement/control objective.

The two similar related lists that you see for Control, Risk, and Control/Risk when you configure the related list has different queries. If you would display one pair of both similar related list, open a profile type and go to the related list's filter and right-click on it and select 'Open new window':

You would notice that the first related list has a different query from the second: 

https://devxxxx.service-now.com/sn_risk_risk_list.do?sysparm_query=source_list%3D6305c264dbd3330045c6e9c948961956%5E

https://devxxxx.service-now.com/sn_risk_risk_list.do?sysparm_query=profile_type%3D6305c264dbd3330045c6e9c948961956%5E

The first one queries all risks/controls whose source_list is the profile type indicated, while the second one will show all risks/controls using the profile_type value as the filter. Since OOB, the profile_type field is not auto-populated, then the related list is normally empty.

[spacecowboy]

Thanks Dexter!