Platform, Role, and Contextual Security
About 16% of the CIS-HR exam — see all 4 domains.
HRSD layers three kinds of access control; you must distinguish them.
Platform Security (ACLs)
Standard table/field/record ACLs (read/write/create/delete) still apply because HR tables live on the platform. But HRSD intentionally does not rely on Task-level roles alone for HR data.
Role-Based Security (HR roles and groups)
Key HR roles (names prefixed in the HR scope) include, conceptually:
- HR admin (
sn_hr_core.admin): full HRSD configuration. - HR manager (
sn_hr_core.manager): access to all HR cases, HR profiles, and secure HR information; contains the HR basic role. - HR case worker / agent (case writer/reader): reads or works HR cases; these roles cover all HR cases unless COE security policies or case restrictions narrow access.
- HR basic (
sn_hr_core.basic, the HR agent role): basic access for HR staff daily work; contains the HR case writer, profile writer, and KB writer roles. Employees get separate employee roles (for examplesn_hr_core.hrsm_employee).
Agents gain access to HR cases through HR roles (case reader/writer cover all HR cases by default); COE security policies and Employee Relations case restrictions then limit sensitive COEs to permitted groups. Roles are typically delivered through groups, not assigned to users one-by-one. Client role assignment rules can automate role grants.
Contextual Security (COE security, field security, case restrictions)
This is the HRSD-specific layer and a heavy exam focus:
- COE-based access: COE security policies restrict which groups can read or write cases in a COE (HR case reader/writer roles otherwise cover all HR cases); Employee Relations cases are restricted to groups permitted by an ER case restriction configuration (the base system provides one for the HR Confidential group).
- HR case access context: the Opened for and Opened by users, watch list members, and collaborators keep access to a case even where a COE security policy restricts the COE. Assignment or a manager relationship is not by itself a documented grant.
- Field-level security in HR hides/secures individual profile fields (e.g., SSN/tax ID encryption).
- Employee Relations case restrictions and the COE security policy add the strictest gating: only members of groups permitted by an ER case restriction configuration (holding the sn_hr_er.confidential role) can view restricted ER cases; ER also adds involved-parties, allegations, and evidence with their own access controls.
- VIP / special handling notes alert agents that a subject needs discreet treatment; they inform agents rather than restrict access.
Mental model: Platform ACL says the table is readable → HR role says you're an HR person → COE/criteria/contextual security says you're allowed THIS case. All layers must pass.
Sample questions from this domain
Three of the 48 in this domain, with the reasoning. The full set is in the question bank.
What is the primary purpose of contextual security (ACLs) on HR data?
- A. To control create, read, write, and delete access to HR records and fields based on roles and conditions ✓
- B. To control which HR catalog items and topics employees can see and request in Employee Center
- C. To control which form fields are visible, mandatory, or editable while an agent works on an HR case
- D. To control which HR services an agent can select for an employee when creating a new HR case in the workspace
Why: Contextual security in HRSD is built on ACLs, which control create, read, write, and delete access to HR records and fields based on roles and conditions, enforced on the server. Which catalog items and topics employees can see is set by user criteria, making fields visible, mandatory, or editable on the form is UI policy behavior, and which HR services an agent can select in Create New Case is filtered by HR criteria on the HR service.
Which HR role typically allows a user to work HR cases as an HR agent/case worker?
- A. The HR case reader role [sn_hr_core.case_reader], which grants read on HR cases
- B. The HR profile writer role [sn_hr_core.profile_writer] for editing HR profiles
- C. An HR agent role such as HR case writer [sn_hr_core.case_writer] (or HR agent [sn_hr_core.basic]) ✓
- D. The Employee Relations confidential role [sn_hr_er.confidential] for restricted Employee Relations cases
Why: Working HR cases requires an HR agent role: HR case writer [sn_hr_core.case_writer] can read and write all HR cases, and HR agent [sn_hr_core.basic] contains case writer along with profile writer and knowledge writer for day-to-day agent work in HR Agent Workspace. HR case reader is read-only, so it cannot work cases, and HR profile writer edits HR profiles rather than cases. The sn_hr_er.confidential role is held by members of authorized groups to reach restricted Employee Relations cases; it is not the role that makes someone an HR agent.
How does HRSD typically restrict HR agents to only the COE(s) they are responsible for?
- A. By giving each COE its own scoped application so cross-COE reads are blocked
- B. Through COE-specific groups and contextual security so agents only access their COE's data ✓
- C. Through HR criteria on each HR service so agents see only their COE's cases
- D. Through HR assignment rules, so agents can open only the cases that are routed to their own group
Why: COE-specific groups combined with contextual security (active COE security policies, implemented as ACLs, that grant read or write access to the groups they list) restrict agents to their COE's data. COEs are extension tables of sn_hr_core_case inside HR Core, not separate scoped applications. HR criteria on an HR service only filter what an agent can request for an employee in Create New Case, and assignment rules route work without granting or limiting access to cases.