‹ All interview questions

Security

You're supporting a production scoped application that needs to read and update records in the global…

Senior · ServiceNow · Feb 2026

The question

You're supporting a production scoped application that needs to read and update records in the global Incident table from within a business rule. Developers report intermittent 'cross-scope access denied' errors, but the errors don't occur consistently—sometimes the same code works, sometimes it fails. The table's Application Access tab shows 'Can read' and 'Can update' are checked. Walk me through your diagnostic approach: what would you check first, what are the root causes you'd investigate, and what solution would you recommend with trade-offs?

Why This Comes Up in Interviews

This scenario tests whether candidates understand that cross-scope access failures have multiple layers: table-level permissions, sys_scope_privilege records, restricted caller access policies, and execution context. The intermittent nature suggests the issue isn't simply missing table permissions—it's likely a missing or incorrectly configured cross-scope privilege record or restricted caller access configuration that only triggers under specific conditions (certain user roles, API calls vs. UI operations, or async execution).

Diagnostic Approach

First, verify the basics: Confirm the table's Application Access settings are correct, but recognize this alone is insufficient. The presence of 'Can read' and 'Can update' doesn't guarantee cross-scope access—it only allows other scopes to access the table if proper cross-scope privilege records exist.

Second, check sys_scope_privilege records: Navigate to System Applications > Cross-Scope Privileges and filter for Source Scope = your scoped app and Target Scope = global. Look for 'Requested' status records that need approval, or missing records entirely. This is where the actual permission grant happens. An 'Allowed' record must exist for read, create, and update operations separately.

Third, investigate restricted caller access: If using APIs or if the error occurs only for certain operations, check System Applications > Restricted Caller Access Privileges. Some operations (especially setValue on global scope tables from scoped apps) require explicit entries here, not just table-level permissions.

Fourth, examine execution context: Intermittent failures often indicate the code runs under different user contexts. Business rules execute as the current user—if that user lacks permissions, the cross-scope access fails. Check if certain user roles or service accounts have different privilege levels.

The Solution

// PROBLEM: Inconsistent cross-scope access errors
var incident = new GlideRecord('incident');
incident.get('abc123');
incident.setValue('state', '2'); // Sometimes fails with cross-scope error
incident.update();
// SOLUTION: Execute in global scope context
var incident = new GlideRecord('incident');
incident.get('abc123');
// Ensure cross-scope privilege exists: 
// sys_scope_privilege record with Source=your_scope, 
// Target=global, Operation=write, State=Allowed
// Use a global-scoped script include to handle the update
var globalUtil = new global.IncidentUtil();
globalUtil.updateIncidentState('abc123', '2');
// GLOBAL SCOPE SCRIPT INCLUDE (IncidentUtil):
var IncidentUtil = Class.create();
IncidentUtil.prototype = {
  updateIncidentState: function(incidentId, newState) {
    var incident = new GlideRecord('incident');
    incident.get(incidentId);
    incident.setValue('state', newState);
    incident.update();
    return true;
  },
  type: 'IncidentUtil'
};

Senior Considerations

  • Multiple solution paths with trade-offs: Moving logic to a global script include (shown above) is more reliable but creates tight coupling. Alternatively, configure cross-scope privilege records properly and execute in scoped context—this requires more upfront configuration but maintains better separation. A third option is using REST APIs with proper OAuth tokens, which is most flexible for distributed systems but adds latency.
  • Root cause vs. symptom: Great answers distinguish between 'the table permissions are wrong' and 'the cross-scope privilege record is missing.' Both cause the same error, but solutions differ. Intermittent failures specifically point to missing sys_scope_privilege records—they only fail when the system enforces the policy, not always.
  • Production considerations: Explain why this matters: scoped apps in production often have multiple users with different roles. A solution that works for admin users might fail for regular fulfilllers if restricted caller access isn't configured. Also mention that cross-scope privilege records are promotion-sensitive—they may not move between environments, requiring re-configuration in production.
  • Scalability and maintenance: Moving all cross-scope operations to global script includes creates a bottleneck and makes scoped app logic harder to test independently. Proper cross-scope privilege configuration is more maintainable long-term, even if it requires more setup.
  • Debugging technique: Mention enabling sys_scope_privilege logging or checking the system log for specific cross-scope denial messages—these logs show exactly which operation was denied and from which scope, making diagnosis much faster than guessing.
  • What separates great from good: Good answers identify the problem and propose a solution. Great answers explain why the problem occurs intermittently, walk through the three-layer permission model (table access, cross-scope privileges, restricted caller access), discuss trade-offs between solutions, and explain production implications around environment promotion and user context.