Empty Requested Item Table

[shahiedsali]

Hello Community,

I have an issue where user A is not able to see records on the requested item table (sc_req_item). User B/C/D are able to see the records. Currently, the table just shows blank and it does not have the 'number of rows removed from this list by security constraints'.

Upon using the access analyser, all users have the sameACLs passed on 'read', 'report_on', 'query_range', 'query_match' for the requested item table. I have asked user A to clear his cache but it does not work. I have checked Business Rules for 'before' AND 'Query' is true, there is one, but it does not affect other users except user A.

Appreciate any inputs from the community, thank you.

[Ankur Bawiskar]

@shahiedsali 

any query business rule is blocking the records for that specific user?

Did you try to impersonate with that user and verify?

Did you use access analyzer and compare both the user records to see any role difference etc?

[Bhavya11]

hi @shahiedsali ,

If your ACL's show the user has access and a list view is not showing 'Number of rows removed from this list by Security constraints: XX' at bottom of page? then the records may be hidden by a query business rule.
If the list view shows 'Number of rows removed from this list by Security constraints: XX' then it is an ACL issue.
Do you have a table level (table.none) read ACL, as well as table.* read configured for the role?

[shahiedsali]

Hello @Ankur Bawiskar and @Bhavya11 ,

Thank you for your responses. I will check for any query business rule for the requested item table. Also as per policy restrictions at work, I am not able to impersonate the user on the production instance. Also, I highly suspect it is not an ACL issue, as the classic list view is not showing the 'Number of rows removed from this list by Security constraints: XX' at the bottom of the page.

Will update here when I found the root cause, thank you all.

[John Gilmore]

I administer an instance where we have multi-sso setup with one sso for internal accounts and another for external accounts. However, because of our specific configuration we end up in situations where users have accounts in both sso sources that use the same basic information. As a result if they come into servicenow from the wrong source and aren't paying attention they can end up being on the account that is associated with the external sso instead of the internal and this is exactly what the ticket we get looks like. If you are in an instance with a similar configuration to this, make sure the user is logged in on the account they think they are.