Scoping / HR Roles FAQ



The purpose of this document is to define best practices and frequent questions about scoping in the context of the HR plugins and scoped roles that are contained with them. We have received quite a few questions about the scoped roles, configuration, and scoping best practices. This document also includes links to other documents where appropriate. 

To start, if you're fairly new to scoping this is a great community article that describes the concept at a high level. Please read this first as it will provide a good background for the context of the rest of this document:

Understanding Application Scope on the Now Platform

The latest Plugins for the Human Resources Service Management application are all implemented as separate scoped applications. Each scoped application has a "scoped admin" role that allows admin privileges for components to anyone that has the role. This is a list of plugins and roles: 

HR Plugins and Scoped Roles Overview


Plugin NameAdmin Role

 Human Resources Scoped App: Core


 Human Resources Scoped App: Service Portal


 Human Resources Scoped App: Integrations


 Human Resources Scoped App: Data Migration


 Human Resources Scoped App: Lifecycle Events


 Human Resources Scoped App: Employee Document Files


 Human Resources Scoped App: Virtual Agent Conversations


Each scoped application/plugin above has its own set of scoped roles that can only be granted by the "scoped admin" or "designated developer."  This is regardless of whether it's granted by assigning the scoped role directly to a user or adding a user to a group that contains the scoped role.   When one of the HR plugins is first installed, this scoped admin role is added as a child to the standard "admin" role. This allows any user with an admin role to grant these scoped roles to users that will be administering the HRSM application. Once a user has been given the admin role as well as a designated developer(below), they can fully administer the scoped application
Please note, for users that aren't concerned with IT having access to the HR data, the standard system admin will be able to completely administer the application by default after the plugins are installed. For added security for the HR scope, most customers will likely want to remove the scoped role from the "admin" role after setting up designated developers. This will allow HR scoped administrators to have full control of the application. 

Delegated Developer

Once a user has one of the scoped admin roles above, they need to be given the role of Delegated Developer before they can change any of the components in the scope(tables, business rules, the script includes, etc.) Doing this is fairly straightforward and this documentation details it: 

Currently, only the system admin can grant delegated developer roles so this needs to be done before the scoped roles are removed from the admin role. The instructions above apply to adding a delegated developer to any of the scoped admin roles.


Restricted Caller Access

Another common question comes from users seeing error messages when using the HR Application. These error messages will look like the following one: 

These can occur if certain scoped resources (tables, the script includes, etc) are set to deny access to other scopes. To address this a scoped administrator would need to update the Restricted Caller Access record(sys_restricted_caller_access) to allow other scopes to access it. More specific information on how to do this can be found in our official documentation, please see:

A good community blog that talks about how to fix restricted caller access errors:

HR Roles

The main purpose of HR roles is to prevent users outside of the HR organization from accessing HR data.  

Some key points are:

This documentation talks about how to manage HR Roles and has lots of useful information:

Manage HR roles

The below doc lists the roles installed with Case and Knowledge Management:

Roles installed with Case and Knowledge Management