General Scoping/Roles FAQ for HR Plugins

Michael Reade · ‎07-18-2018

Introduction

The purpose of this document is to define best practices and answer 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 applicable.

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 admin roles:

HR Plugins and Scoped Roles Overview

Plugin Name	Admin Role
Human Resources Scoped App: Core	sn_hr_core.admin
Human Resources Scoped App: Service Portal	sn_hr_sp.admin
Human Resources Scoped App: Integrations	sn_hr_integration.admin
Human Resources Scoped App: Data Migration	sn_hr_migration.admin
Human Resources Scoped App: Lifecycle Events	sn_hr_le.admin
Human Resources Scoped App: Employee Document Files	sn_hr_ef.admin
Human Resources Scoped App: Virtual Agent Conversations	sn_hr_va.admin

Each scoped application/plugin above has it's own set of non-admin scoped roles that can only be granted by the scoped admin. When one of the HR plugins is first installed, it's scoped admin role is added as a child role to the standard system administrator role. This allows any user with this system administrator role to grant these scoped roles to users that will be administering the HRSM applications. Once a user has been given the admin role as well as designated developer(below), they can fully administer a 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 any HR scoped 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 to administer 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, script includes, etc.) Doing this is fairly straightforward and this documentation details it:

Add Delegated Developer to HR Administrator

Currently only the system admin can grant delegated developer roles, so this needs to be done before the scoped admin roles are removed from the system admin role. The instructions above apply to adding 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, 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:

FAQ

Q: Why can't I grant a scoped role to a user?
- A: All roles in a 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 seperate 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 a "whitelist" of APIs that the platform will allow scoped applications to call. This whitelist can be found here: API Reference Server Side Scoped
Q: Why don't I see my scoped roles or my scoped roles taking affect after they are granted to a user.
- A: Users will need to log out and log back in after being granted a role.