Security, Users, Roles, and Data Access
What the exam tests
Security questions test whether you can model users, roles, privileges, and data access without over-permissioning. Know how job roles, abstract roles, and data security policies combine to grant access to cases, knowledge, and queues.
Core rules and concepts
- A user gets access through role assignments; roles aggregate privileges. Privileges control actions; data security policies control which records those actions apply to.
- Use job roles for business functions (agent, supervisor, knowledge manager) and abstract roles for cross-functional access. Avoid assigning individual privileges directly.
- Data access can be constrained by organization, territory, queue, catalog, or case type. Design policies around the broadest safe scope, then test with a real user.
- SSO and identity federation should be configured before user provisioning; deprovisioning must revoke roles and sessions.
- Queue membership is both a routing and an access decision; do not assume queue access equals record access.
Worked example
A partner agent should see only cases for their own account and must not see internal knowledge drafts. Assign the partner agent job role with case privileges, add a data security policy filtering cases by partner account, and remove knowledge authoring privileges. Then test by signing in as the partner: the case list should show only their account, and knowledge search should return published external articles only. The reasoning: privileges alone would expose all cases; the data policy narrows rows, and role design removes the knowledge action.
Traps
- Giving superuser or administrator roles to implementation users who only need configuration access.
- Confusing role membership with data access; a role does not automatically filter records.
- Forgetting that queue membership can expose records if data policies are broad.
- Not testing negative cases: what a user must not see.