Access Analyzer says "Passed" but sys_user list columns are completely blank (OOTB Instance)

[jordimsant]

Hi everyone,

I am facing a very strange issue on a brand new, completely clean OOTB (Out-Of-The-Box) demo instance with zero customizations.

When a specific non-admin user (G. Geimer) accesses the User (sys_user) table list view, almost all key columns appear completely empty (such as User ID, Email, Active, Created, and Updated). The only column that actually renders data is the Name field.

To troubleshoot, I used the Access Analyzer to check why the platform is hiding this data. To my surprise, the tool shows that everything is fine:

• Table Read Access: Passed

• Field Read Access (e.g., first_name): Passed (All ACLs, Data Filtration, and Access Handlers return a green "Passed" status for the read operation).

The Evidence:

1. Admin List View (Everything is visible):

   

2. User List View (everything is white):

    

3. Access Analyzer - Table Level (sys_user):

    

4. Field Level (sys_user.first_name):

    

My Question:

If the Access Analyzer explicitly states that the user passes the security checks to read both the table and the specific fields, why is the OOTB user interface still rendering these columns completely blank? 

Since this is a brand new demo instance, there are no custom Before Query Business Rules, no custom Data Masking, and no custom ACLs overriding the behavior. Has anyone encountered this OOTB behavior on the sys_user table? What native platform mechanism or hidden constraint is causing Access Analyzer to say "Passed" while the UI suppresses the data?

Thanks in advance for your insights!

[Tanushree Maiti]

Hi @jordimsant 

1. Check 

KB0725733 Field values displayed on the form but list shows empty columns 

2. As you are using OOB instance , in that case I will suggest you to raise a case to your ServiceNow Vendor. 

[jordimsant]

I am sure there must be an easy explanation for these. I mean, we are talking about sys_user table in a demo instance, I cannot be the first person that finds this out

[Philippe Casidy]

Hi @jordimsant 

As per my understanding the user G**la (I understand now why you typed only G) in a PDI has no specific role.

As such, this person can only see others First Names and Last Names.

But this person should be able to access own data, so by default "Read" access is granted.

Try checking the access on another person's "Home Phone" for example:

Philippe

[jordimsant · Accepted solution]

Hi everyone,

I wanted to share an update on this because I finally found the root cause, and it turns out it was a misunderstanding of how the tool behaves rather than a platform bug.

First of all, I have to say that Access Analyzer is an absolutely fantastic tool. If you are working with ACLs or troubleshooting permissions in ServiceNow, I highly, highly recommend using it. It saves a ton of time. However, you need to be careful with how you configure the analyzer scope.

The Catch with Access Analyzer Scope

When I ran my initial test, I was only analyzing permissions by providing the Table name (sys_user).

• What I expected: I thought evaluating the table level would automatically drill down and give me an accurate picture of the fields.

• What actually happens: When you only provide the table, the tool primarily evaluates table-level ACLs. Because the user had table-level read access, it returned a green "Passed" status.

The Solution

The breakthrough came when I realized you can (and should) be more specific. If you suspect field-level issues, you need to explicitly change the scope in Access Analyzer to target a Specific Record or a Specific Field.

Once I ran the analyzer again—this time specifying the exact fields that were showing up blank—the tool perfectly flagged the restriction: it immediately showed that certain field-level ACLs were indeed failing for that specific non-admin user. If you are not familiarized with different ACL types, I recommend you reading this article.

My Recommendation

If you are using Access Analyzer to debug empty columns or missing UI data, don't just stop at the table level. Make sure you:

1. Select the specific fields or evaluate a concrete record.

2. Remember that a green "Passed" at the table level does not mean the user has rights to see every single field within that table.

Hopefully, this helps anyone else who might get tripped up by this OOTB behavior!