How to troubleshoot cross scope security restricted access denied errors - Support and Troubleshooting

How to troubleshoot cross scope security restricted access denied errors .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Table of Contents: Description Background: the three security layers Troubleshooting steps Issue 1 — Refused due to the table's cross-scope access policy Issue 2 — Application must declare a cross-scope access privilege Issue 3 — Source descriptor is empty / source could not be found Issue 4 — Cross-scope access privilege denied (RCA set to Denied) Quick decision tree References Description When code running in one application scope reads, writes, creates, deletes, or executes a resource that lives in another scope, ServiceNow enforces several security layers. If any layer denies the request, a "Security restricted" message is thrown and the operation is blocked.

This article covers the four most common cross-scope error messages, explains exactly which layer is denying the request, and gives a step-by-step fix for each. Examples use Read on a table; the same pattern applies to Write, Create, Delete, and Execute API.

Background: the three security layers

Before working through the issues, it helps to know what is being checked, in this order:

1. Application Access on the target table (sys_db_object) - Field Accessible from: All application scopes vs. This application scope only. - Per-operation flags: Can read, Can create, Can update, Can delete. - If the table is restricted to its own scope, no cross-scope access is possible. 2. Cross-Scope Privilege record (sys_scope_privilege) - Declares that has been granted on 's resource. - Normally auto-created in Allowed state the first time the calling scope performs the operation. May exist in Requested or Denied state and block the call. 3. Restricted Caller Access (RCA) record (sys_restricted_caller_access) - Only evaluated when the target table's Caller Access is set to Caller Tracking or Caller Restriction. - Each calling source (scope, application, script) needs its own Allowed record to call into the protected resource.

The four issues below each correspond to a failure at one of those layers.

Troubleshooting steps Issue 1 — Refused due to the table's cross-scope access policy Error message Security restricted: Read operation against ' ' from scope ' ' has been refused due to the table's cross-scope access policy

Why this happens

The target table's Application Access > Accessible from is set to This application scope only. No record on any other table can grant the access — the table itself opts out of cross-scope reads.

Resolution (step by step)

1. As an admin, switch into the application that owns (the application picker in the top header). 2. Navigate to System Definition > Tables and open the sys_db_object record for . 3. Scroll to the Application Access section. 4. Verify each field: - Accessible from — change from This application scope only to All application scopes. - Can read — check the box (or the appropriate box: Can create, Can update, Can delete, depending on ). 5. Review Caller Access on the same form: - If None: no additional steps required beyond the cross-scope privilege (see Issue 2). - If Caller Tracking or Caller Restriction: an RCA record will also be required (see Issue 3). 6. Save the form. 7. Re-run the failing operation from .

Notes and cautions

- Changing Accessible from to All application scopes is a security decision owned by the application's author/admin. Do not change this on a third-party application — instead, contact the application's vendor or developer. - If you cannot modify the table, the operation cannot succeed from another scope. The calling code must be moved into (or the data accessed through a scoped API exposed by ).

Issue 2 — Application must declare a cross-scope access privilege Error message Security restricted: Read operation on table ' ' from scope ' ' was denied. The application ' ' must declare a cross scope access privilege. Please contact the application author to update their privilege requests.

Why this happens

The target table allows cross-scope access (Issue 1 is already resolved), and Caller Access on the table is None. The platform now checks sys_scope_privilege for an Allowed record granting the requested against . Either: - no record exists, or - a record exists but its Status is Requested or Denied.

Resolution (step by step)

1. As an admin, navigate to System Applications > Application Cross-Scope Access (or open the list directly: sys_scope_privilege.list). 2. Filter for a matching record: - Source Scope = - Target Scope = - Target Name = - Target Type = Table - Operation = (e.g., Read) 3. If a record exists with Status = Requested or Denied: - Open it, set Status = Allowed, and Save. 4. If no record exists: - Click New, fill in the fields above, set Status = Allowed, and Save. 5. Re-run the failing operation from .

Notes and cautions

- Cross-scope privilege records are normally auto-created in Allowed state the first time a scope performs the operation, so seeing this error usually means the auto-create was blocked (e.g., by a prior Denied record) or that the privilege was manually revoked. - The change should be made/owned by the source application's author. Adding a privilege record is essentially declaring "this app needs that access" — record the business reason in the Description field for auditability.

Issue 3 — Source descriptor is empty / source could not be found

Error message(s) Source descriptor is empty while recording access for table : no thrown error followed by: Security restricted: Read operation on table ' ' from scope ' ' was denied because the source could not be found.Please contact the application admin.

Why this happens

- The target table allows cross-scope access (Issue 1 is resolved). - The target table's Caller Access is set to Caller Restriction (or Caller Tracking in restriction-enforcing mode). - No sys_restricted_caller_access (RCA) record exists for the calling source. Because RCA tracks the caller (the specific scope/script/processor making the call), the platform cannot find an entry for the current source — hence "source descriptor is empty / source could not be found".

Resolution (step by step)

1. As an admin, navigate to System Security > Restricted Caller Access (or open the list directly: sys_restricted_caller_access.list). 2. Click New and populate: - Source Scope = - Source Type = Application (use this when the caller is an entire scope; use Scriptable, Processor, etc. when granting at a more specific level — see References) - Target Scope = - Target Type = Table - Target Name = (set this to the table's Name, e.g., x_snc_xyz_mytable) - Operation = (e.g., Read) - Status = Allowed 3. Save the record. 4. Re-run the failing operation from .

Notes and cautions

- If Caller Access does not need to be Caller Restriction, an alternative is to lower it (e.g., to None) on the target table — but only the target application's owner should make that call, and only if the elevated protection is not required. - Make sure you also have a corresponding sys_scope_privilege record in Allowed state (Issue 2). RCA does not replace the cross-scope privilege; both layers are checked.

Issue 4 — Cross-scope access privilege denied (RCA set to Denied)

Error message Security restricted: Read operation on table ' ' from scope ' ' was denied. The application ' ' must declare a cross scope access privilege. Please contact the application admin to update their access requests.

- How this differs from Issue 2: the wording is very similar, but it ends with "update their access requests" (RCA) instead of "update their privilege requests" (cross-scope privilege). This error appears when Caller Access on the target table is Caller Restriction and an RCA record exists but its Status is Denied (or Requested).

Why this happens

- The target table allows cross-scope access. - The target table's Caller Access is set to Caller Restriction. - A sys_restricted_caller_access record exists for → , but its Status is Denied.

Resolution (step by step)

1. As an admin, navigate to System Security > Restricted Caller Access (sys_restricted_caller_access.list). 2. Filter for: - Source Scope = - Target Scope = - Target Name = - Operation = 3. Open the matching record. Verify its Status field. 4. If Status = Denied or Requested, change it to Allowed and Save.

Notes and cautions

- Before flipping a Denied RCA record to Allowed, confirm with the target application's owner that the access is intentional. A Denied RCA is usually deliberate. - Always check the sys_scope_privilege record as well — if it is also Denied or Requested, you'll continue to see Issue 2 errors after fixing the RCA. - The target table's Caller Access is set to Caller Restriction. - A sys_restricted_caller_access record exists for → , but its Status is Denied.

Resolution (step by step)

1. As an admin, navigate to System Security > Restricted Caller Access (sys_restricted_caller_access.list). 2. Filter for: - Source Scope = - Target Scope = - Target Name = - Operation = 3. Open the matching record. Verify its Status field. 4. If Status = Denied or Requested, change it to Allowed and Save. 5. Re-run the failing operation from .

Notes and cautions

- Before flipping a Denied RCA record to Allowed, confirm with the target application's owner that the access is intentional. A Denied RCA is usually deliberate. - Always check the sys_scope_privilege record as well — if it is also Denied or Requested, you'll continue to see Issue 2 errors after fixing the RCA.

Quick decision tree Use the exact error message to route to the right fix:

┌────────────────────────────────────────────────────┐ │ Error contains... │ Layer at fault │ Go to │ ├────────────────────────────────────────────────────┤ │ "refused due to the table's cross-scope access policy" │ Table's Accessible from │ Issue 1 │ ├────────────────────────────────────────────────────┤ │ "must declare a cross scope access privilege ... privilege requests" │ sys_scope_privilege missing/denied │ Issue 2 │ ├────────────────────────────────────────────────────┤ │ "source descriptor is empty" / "source could not be found" │ sys_restricted_caller_access missing │ Issue 3 │ ├────────────────────────────────────────────────────┤ │ "must declare a cross scope access privilege ... access requests" │ sys_restricted_caller_access denied │ Issue 4 │ └────────────────────────────────────────────────────┘

All four examples are written for Read. The same logic applies to Write, Create, Delete, and Execute API — replace in the matching sys_scope_privilege and sys_restricted_caller_access records.

References https://docs.servicenow.com/bundle/washingtondc-application-development/page/build/applications/reference/c_CrossScopePrivilegeRecord.html https://developer.servicenow.com/dev.do#!/learn/learning-plans/washingtondc/new_to_servicenow/app_store_learnv2_securingapps_washingtondc_application_access https://docs.servicenow.com/bundle/washingtondc-application-development/page/build/applications/concept/restricted-caller-access-privilege.html https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0745465 https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0820672