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 Name||Admin 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.
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:
- "Read operation on table "tablex" from scope "Human Resources: Service Portal" was denied. The application must declare a cross scope access privilege"
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:
The main purpose of HR roles is to prevent users outside of the HR organization from accessing HR data.
Some key points are:
- Users without an HR scoped role cannot view HR cases or HR profile information.
- Only a HR Administrator [sn_hr_core.admin] can assign scoped HR roles. This is enforced regardless of whether the scoped role is assigned directly to the user or the user is added to a group that contains the scoped role.
- By default, the system admin role (admin) contains the HR admin role (sn_hr_core.admin). Ensure to configure your system such that only the HR admin role has access to sensitive information. After assigning the HR admin role to the necessary users, remove the HR admin role from the system admin role to prevent the System Administrator from viewing sensitive HR information. Note: Ensure that you have at least two users with the HR Administrator role. If you assign only one person with the role and that person is deactivated, you no longer have a user that can perform the HR admin duties. See Remove HR Administrator role from IT System Administrator.
- System admin can impersonate HR admin, but can't perform HR-related stuff.
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
- Q: Why can't I grant a scoped role to a user?
- A: All roles in scope can only be granted by a user with the scoped admin role.
- Q: Will global ACLs be honored by scoped applications? If there is a scoped application querying the user table, will global ACLs on that table work?
- A: Not at this time. Global ACLs need to be copied into a separate ACL in the scoped application.
- Q: Can I still call all the APIs and platform script includes that I can in the Global space?
- A: No there is an "inclusion list" of APIs that the platform will allow scoped applications to call. This inclusion list can be found here: API Reference Server Side Scoped
- Q: Why don't I see my scoped roles or my scoped roles taking effect after they are granted to a user.
- A: Users will need to log out and log back in after being granted a role.
- Q: Why can't I see some HR services or COE tables on the native Case Creation UI Page (sn_hr_core_case_creation.do)?
- A: Check the case tables ACLs to see if they are customized
- Q: Why are some HR profile fields are not editable by the employee?
- A: Some HR profile fields can be configured to be hidden/shown to employees using an HR system property (sn_hr_core.hr_profile_editable_fields). See Add or modify an HR profile
- Q: Why am I not able to add users to a group, which contains scoped application roles (e.g. sn_hr_core.basic)?
- A: Scoped application roles can only be assigned by users who have a role specified in the assignable by field of the scoped application role. In the example above, the user needs to have the role sn_hr_core.admin which is the assignable by field of the sn_hr_core.basic role. See KB0722958 for details.
- Q: Why can't I see certain HR services created in "Human Resources: Service Portal" scope during case creation even though I have the sn_hr_core.basic role?
- A: Scoped ACL will only be evaluated for records created in the same scope as the ACL record. In the example above, there is no ACL that grants read access for HR services created in "Human Resources: Service Portal" scope. The ACL that grants read access to HR services is in "Human Resources: Core" scope. The solution is to create the same read ACL in "Human Resources: Service Portal" scope. See KB KB0780734.
- Q: Why can't I see sys_audit records of sn_hr_core_case?
- A: sn_hr_core.admin role is required to read audit records