Scoped Application Roles Unable to Access core_company Reference Field Despite ACLs and Cross-Scope

[mkm1]

When using the core_company field as a reference field in a custom table, the reference field is not accessible to the scoped application roles. All the 'read', 'write', and 'create' ACLs are in place for the specific scoped role, but the reference data is not visible to the scoped role.

Added Cross-Scope Privileges explicitly allow cross-scope access for the core_company table, still the reference field is not accessible and visible to the scoped role. ServiceNow best practices do not recommend extending the core_company table, but using it as a reference has its issues.

Attached files with screenshots of:

• 'Company List - Visible to System Admin'
• 'Company List - Visible to scoped role'
• 'Cross scope read privilege for core_company'
• 'Company ACL - Read'

[Anish Reghu]

Hi @mkm1,

The root of the problem is the conflict between the scoped application's desire to reference global data and the ServiceNow platform’s enforcement of cross‑scope data boundaries, especially for core tables like core_company. The two recommended approaches are:

1. Create a custom company table in your scoped app and synchronize data from core_company into it, then update your reference field to target your custom table. This aligns with best practices by keeping your scoped data fully within your application’s control.

2. Remove the direct reference and instead copy the necessary company details into your custom table, which also avoids reliance on cross‑scope reference logic.

Regards,

Anish Reghu

[mkm1]

For the scoped application, I worked with the ServiceNow certification team, who recommended best practices, including avoiding the extension of core tables such as core_company, cmn_department, and sys_user. Instead, we created custom tables that reference these core tables respectively.

To address access restrictions imposed by the out-of-the-box (OTB) ACL on the core_company table, we created a custom ACL specifically for scoped roles.

One drawback of this approach is that you won't be able to use dictionary overrides on core table attributes. Additionally, if your scoped application extends the task table, avoid modifying reference fields that point to core tables, as this could alter default behaviors. Instead, create custom reference fields that point to your custom tables and implement any additional functionality as needed for your scoped application.