Current Behavior:

According to Add or remove page restrictions, the Request Access feature works by notifying users whoever is in the best position to grant permission to a page, using this logic in order:

1. Our first choice is the page owner or page creator. Creator will not be checked if the owner exists.
2. If the page owner/creator is unable to grant permission (if their account is deactivated or if their page access has been revoked or if the user doesn't have Add/Remove Restrictions permissions on the space), then we’ll send the email to the last person who updated the page (again if they exist and have Add/Remove Restrictions permissions on the space)
   Note: We do not consider the full list of page modifiers. If the most recent modifier fails, we move to the next check.
3. Then we’ll send the email to a space admin alphabetically (space admins who atleast have view access to the restricted page)

Now, for enterprise customers where point 1,2,3 are limited and all site admins are added as space admins to all the spaces (via site-admins or administrators group) and are also added to the restricted pages atleast with view access, are facing issues, where a site admin whose name is starting with A is getting bombarded with all the access requests for the restricted pages.

Suggestions:

Add/Delete Restriction permission should also apply for space admins. So that even space admins who don't have Add/Delete Restriction permission checked for them (or the group) in the space settings, don't get the access requests.

AND

The space admin/user who has added Restrictions to the page should be prioritized for access requests for that particular page instead of blindly following the alphabetical order for space admins.

AND

Remove the single space admin name that is notified from the popup window notifying the requesting user that a space admin has been notified.