Why won't my related lists display for non-admin users?

[dclayne]

As an admin, while in the form of a custom application, I selected the Additional --> Configure --> Related Lists option and added the appropriate selection to the form (e.g. the child table has a reference field that obtains its value from the table I'm adding the related list to). This related list displays wonderfully for admins, but not for non-admins.

Here is a screen capture of the form when an admin views it...notice the tabbed region beneath the UI Actions and the hierarchical related lists:

Here is a screen capture of the same form and same data when a non-admin views it...notice there are no related lists beneath the UI Actions:

When I modify the form design and make the Related Lists part of the Form Layout (e.g. as Embedded Lists), the data displays with the only issue being that it looks ugly:

The Related List display issue occurs in domain-separated and non-domain - separated environments. It occurs regardless of the user's domain (e.g. an admin in all the different domains can see the related lists, but a non-admin in any of the domains, including global, cannot.)

So, this leads me to the following questions: are defined Related Lists only available for admins; or, am I missing some table attribute, ACL rule, or system role that would allow my non-admin to see the related lists? I really don't want to use form-embedded lists. Based on the type of data entry that's required, related lists would be much better for the user experience.

[dclayne]

Hi Donnie,

I did note down a difference in the HTML:

Admin user:

<div id="tabs2_spacer"><div style="margin:0px; padding:0px;" id="related_lists_wrapper" class="tabs_enabled"><script>window.__ltmr = new Date();</script><link type="text/css" rel="stylesheet" href="/styles/listDND.cssx?v=09-15-2016_0944"><script>

// GlideList2 initialization

var f = function() {

...

(about 729 lines of code until the close tag)

Non-admin user:

<div id="tabs2_spacer"><div style="margin:0px; padding:0px;" id="related_lists_wrapper" class="tabs_disabled"><script>CustomEvent.fire('related_lists.ready');</script></div></div>

I wish I knew what causes the class=tabs_disabled flag to occur. I tried modifying the non-admin's settings and it has absolutely nothing to do with the user preference of whether to display related lists as tabbed or not.

[dclayne · Accepted solution]

I figured it out! In table sys_security_acl, there's an out-of-the-box ServiceNow ACL named sys_ui_related_list for read functionality, globally scoped, which makes it so that you must have the admin or form_admin role in order to view related lists within a form. I created a new ACL associated with application, also named sys_ui_related_list, with read functionality, and assigned the application's guest and admin roles to that new application-specific ACL. Now, when I view the forms as a non-admin, I'm able to see the related lists.

[jboiteux]

David,

Had a similar issue and what you proposed worked for me.   Honestly, not sure why as when I review it under my personal developer instance it worked fine without the ACL.   I was trying to display the Time Worked related list and would only show for admins without the ACL change.   All other related list would show without doing any modifications.   Nonetheless thanks for you the suggestion!

[dclayne]

Thanks, Jean! I'm really happy you were able to find the answer you were looking for in the community forums! 🙂

I wonder if your issue was related to different domain scopes. In your developer instance, you were probably in the global scope already, hence the OOB ACLs worked just fine, but in your other environment, your domain corresponding to the Time Worked table (part of a scoped application?) and/or table values (domain separated?) were likely not in the global scope, hence the need for the ACL.

Personally, I think it's very strange that the people who developed ServiceNow only want admins to be able to see related lists. They're a useful UI element that reduces clicks for the end-user. Luckily, in a scoped application, one can create an ACL to view related lists just for one's scoped application, so it doesn't affect the entirety of ServiceNow.

[Bryan Cole]

I'm having this issue currently with a scoped application on Madrid, and the solution is not working for me. The proposed solution stands out to me because I don't think the absence of an ACL should cause the related list to be hidden. As I understand it, the ACL evaluation logic should not prevent a user from accessing data if there is no ACL defined. Is anyone still experiencing this issue?

ACL Evaluation: https://docs.servicenow.com/bundle/newyork-platform-administration/page/administer/contextual-securi...