sys_restricted_caller_access records are being created in sys_update_xml - Support and Troubleshooting

sys_restricted_caller_access records are being created in sys_update_xml Issue Sometimes when viewing certain records or data like images or attachments, we can see sys_restricted_caller_access records within the sys_update_xml table.

These records will often attach themselves to update sets which the client will often have to clear manually.

Here is an example of the sys_update_xml table with these records:

Cause This issue is caused by Cross Scope Privileges.

These records are created due to certain scoped records are trying to access a separate scope. That means, 1 record is crossing scopes to a target scope. You can review some more information regarding Cross Scope Privileges here:

Cross-scope privilege record

Resolution Listed below are the steps involved in finding where the source of these records are being created, and deciding how you'd like to handing the cross scope privileges. 1 . Start with checking sys_update_xml: https:// .service-now.com/nav_to.do?uri=%2Fsys_update_xml_list.do%3Fsysparm_query%3DnameSTARTSWITHsys_restricted_caller_access%26sysparm_first_row%3D1%26sysparm_view%3D%26sysparm_choice_query_raw%3D%26sysparm_list_header_search%3Dtrue We see here that there are quite a few new records. 2 . You read the payload and find near the top " " and " ": write ebc7ec91672222002e640731b2415af7 f38c97005301120034c69816a11c081d sysauto_script 3 2 sys_restricted_caller_access system 2021-01-15 14:11:50 false 13e0ab14dbfda414bb5a4a2813961996 0 82878663ff123100158bffffffffff67 82878663ff123100158bffffffffff67 false 82878663ff123100158bffffffffff67 sys_restricted_caller_access_13e0ab14dbfda414bb5a4a2813961996 system 2021-01-15 14:11:50 d2ec8e6fdbd4241059ac6e25ca96194c 82878663ff123100158bffffffffff67 sys_db_object 1 With the source and source table, you can now find the source of this record: https:// .service-now.com/sysauto_script_list.do?sysparm_query=sys_idSTARTSWITHebc7ec91672222002e640731b2415af7&sysparm_first_row=1&sysparm_view= The source_table is 'sysauto_script', so we go to that table. We then filter out the sys_id found in 'source'. 3 . Now we know the source of the record, we can see which scope is trying to access the other. Near the top of the payload will show the 'source_scope' value. In this case, it is equal to "f38c97005301120034c69816a11c081d", which is for Security Support Common. Now, near the bottom will be the 'target_scope'. The target scope is equal to "82878663ff123100158bffffffffff67", which is for Security Incident Response. Please also note near the top "operation". We see this operation is equal to "write". 4 . Now we understand the scope issue. This is where you decide whether or not to create the cross scope privilege for this record, or leave it be. Do you want to allow this sysauto_script to access this table without having it request the access every time? That will be the question for this type of payload. You can create cross scope privileges by following these resources: https://community.servicenow.com/community?id=community_blog&sys_id=ce28d5b8db690c5c5129a851ca961999 Cross-scope privilege record Define cross-scope access to an application resource Using this information, you should be able to knock down several of these sys_update_xml records. Once you go through all of the sys_update_xml records and add the cross scope privileges where required, this will help clean up how many get created.