I would like to know why users assigned the [approver_user] role can view the "sysapproval_approver"

[bonsai]

I am checking the ACLs for the "sysapproval_approver" table, but I cannot find an ACL that grants read access when the "approver_user" role is assigned...

However, in reality, assigning the "approver_user" role allows access to the "sysapproval_approver" table.

Why is this happening? Is it not being controlled by an ACL?

[Sandeep Rajput · Accepted solution]

@bonsai The role check is applied at the Module level. Only the users with role approver_user can see this module.

[Tanushree Maiti]

Hi @bonsai 

Servicenow designed the tool in that way that to approve a request , one of the role required is approver user.

For that they have added condition / script include in OOB components.

e.g

• ESC portal : Script include ( todoPageUtils) responsible to show the approval request to the approvers . Refer: KB2724728 Employee Center portal - Approvers not able to see approval requests even though they have... 
• For ITSM: Sandeep has already shared . Module based role , For delegated approval checking , script include : ApprovalDelegationUtil  is there

[ajmalmuhamm]

1. This is expected behavior. Access isn't always granted by a table ACL that explicitly lists the approver_user role. It may come from an inherited ACL, a wildcard ACL (*.* or table.*), a scripted ACL, or built-in security logic (such as query business rules or the approval framework). Enabling Debug Security Rules is the best way to identify which security rule is actually granting access.

[bonsai]

I’ve solved it!

The answer lay in the ACL that calls `ApprovalDelegationUtil`.
I had assumed that requesters couldn't have access rights to `sysapproval_approver`, but it turns out that if an approval request is sent to the requester, they *can* access it by running `sysapproval_approver.list`.

However, since the module restricts access to users with the `approver_user` role, it simply isn't visible under normal circumstances.

I tested this by designating a user without the `approver_user` role as the approver;
after performing a delegated action and navigating to the record via `sysapproval_approver.list`, I was able to approve or reject it.
This likely constitutes a licensing violation, but I believe it successfully demonstrates that access isn't being fully controlled.

[Sandeep Rajput]

@bonsai As I mentioned in my previous response, access is usually governed by the access to the module and not via role. Any user in ServiceNow can be an approver. However, only users with approval_user role can actually see those approvals through the module. 

A way to bypass this is by creating a custom widget on the portal to show the list of approvals by making a GlideRecord query to sysapproval_approver or by processing the approvals via inbound email actions where a user can grant approvals via an email.