Read operation on table 'sn_hr_core_profile' from scope 'Global'

manasamaniac · ‎07-21-2018

Hi Team ,

Issue : Below error is being displayed when reading records from HR profile table even though cross priviledges is present and acl is present . How can i resolve this issue. Coss Scope priviledge with Global as scource scope is not allowed .

ERROR :Source descriptor is empty while recording access for table sn_hr_core_profile: no thrown error
Security restricted: Read operation on table 'sn_hr_core_profile' from scope 'Global' was denied because the source could not be found. Please contact the application admin.
Security restricted: Read operation on table 'sn_hr_core_profile' from scope 'Global' was denied. The application 'Global' must declare a cross scope access privilege. Please contact the application admin to update their access requests.

michaelj_sherid · ‎07-21-2018

This is the error you will receive when the Application Restricted CallerAccess record is not "Allowed".

You can go to the Restricted Caller Access form and look for records that do not have the status of "Allowed". It is my theory that tthe operation is making a call into the HR:Core scope that you have not allowed.

This Restricted Caller Access is a new feature in Kingston. This is how we have enhanced the HRSD application to give the HR Administrator more visibility into the operations made against the HR:Core scope.

There is a Community webcast on this new functionality that would give detailed information on this new feature. You can find it here:

https://community.servicenow.com/community?id=community_question&sys_id=cbd8b9badbb9570058dcf4621f961982

Keep us posted and thanks for being part of the Community.

Regards,

Mike

View solution in original post

michaelj_sherid · ‎01-24-2024

@adrian08 you can create a RCA record, but allowing all may open doors that defeats the purpose of the RCA functionality altogether. What works for most customers in cases like this is to allow these during testing to see what RCA records are created. Some customers create these manually given the use case (i.e. there may be a custom script include or table they want to allow calls or execution for). I think this puts you on a better path vs. allowing everything from one scope to another.

Regards,

Mike