A solution/workaround might be not to restrict the entire data-model else only the essential one and having a second (independent) one which is not restricted or with different rule-set. If not all data are restricted the app remains accessible for the user.
Within this second table/data-model are all users with any restrictions listed as well as the information what is why restricted and the what the user should do if he/she thinks they would need an access to which information, like requesting the access by the own supperior which forwarded it to the HR and/or the IT or whatever for a process exists (including already all mails/links for the process-chain).
An alternatively could be also to add some extra/dummy-records within the origin data-set and to link here the get-access-information. I assume that such way would need a bit more testing and would be less generic as the above mentioned logic.
Useful for such an approch would be to provide these information on an extra start-page which is skipped and hide for the regular users and for the complete restricted ones all other sheets are hidden.
The main-efforts would be to add such a start-page and appropriate conditions to show/hide the sheets as well as loading the second table (whereby the approach would be copied/adapted between all relevant apps) - because the work to collect and prepare the access-meta information must be done in any case. And within each application might be at all simpler as if there were any place within the configurations or similar what might be needed to maintain manually or with any API stuff.
