CIS-HR Study Guide: ServiceNow Certified Implementation Specialist, Human Resources (HR Service Delivery)

Trademark disclaimer: ServiceNow, HR Service Delivery, Employee Center, Now Create, and related product and feature names are trademarks of ServiceNow, Inc. This is an independent, original study guide for exam preparation and is not affiliated with, endorsed by, or sponsored by ServiceNow, Inc. All examples are paraphrased from publicly available official documentation; no copyrighted course content is reproduced.

This guide is ordered by exam weight. Spend your time proportionally: the two largest domains (Core HR Applications & HR Service Portal at 41%, HR System Architecture at 36%) together account for roughly three-quarters of the exam. The exam is 45 scored questions in 90 minutes, single-answer and multiple-select.

Domain 2: Core HR Applications and HR Service Portal (41%)

This is the heaviest-weighted domain. It covers how employees and HR agents actually interact with HRSD: the case lifecycle, HR services, the catalog, lifecycle events, the document/employee-file layer, and the Employee Center portal.

HR Services and HR Cases

An HR case is the central work record that an HR agent fulfills. The HR service is the configuration object that defines what a case is about: it carries the COE it belongs to (with its topic category and topic detail), the HR case template, the fulfillment type, the HR criteria that limit which employees an agent can request it for, and the record producer through which employees request it. SLAs come from SLA definitions, not from the HR service. Think of the HR service as the catalog-and-process definition, and the HR case as the live instance of work created from it.

A single HR service can be exposed to employees in more than one way at once:

as a record producer / catalog item in Employee Center,
through Virtual Agent or chat,
created directly by an agent in the Agent Workspace,
generated automatically by a lifecycle event activity.

When you configure an HR service you choose its HR service categorization (the COE, topic category, and topic detail chain; the COE determines which case table the case lands in), the case creation form (the producer the requester fills in) and the case form (what the agent sees). You can also build a child HR service so that fulfilling one service automatically spawns a related downstream case.

Case and Knowledge Management (CKM)

The HR Case and Knowledge Management application is the core fulfillment engine. It provides: case states and the case lifecycle, HR tasks (sub-units of work attached to a case), checklists, approvals, special-handling notes, case transfer/reclassification, escalation, suspend/resume, knowledge article linking, and response (templated) snippets. HR knowledge lives in knowledge bases (the base system provides Human Resources General Knowledge), and user criteria control who can read or contribute to each knowledge base.

HR Service Catalog and Record Producers

In HRSD, employee-facing requests are surfaced through the HR service catalog. The mechanism that turns a form submission into an HR case is the record producer: a record producer presents catalog variables to the employee, then maps those answers onto fields of the target HR case record. Each HR service that is requestable has a record producer behind it. HR catalog items are organized with HR service catalog categorization so they appear in the right place in Employee Center. Editing the record producer for an HR catalog item lets you change the variables, the variable-to-field mapping, and the HR case table it produces.

Lifecycle Events (Enterprise Onboarding and Transitions)

Lifecycle Events (LE) orchestrate multi-step employee journeys such as onboarding, offboarding, and job transfers. The building blocks:

Lifecycle event: the overall journey (e.g., Onboarding).
Activity set: a grouped phase of the journey (e.g., "Before Day 1," "First Week"). Activity sets can be triggered conditionally.
Activity: an individual step. Activity types include approvals, employee tasks, fulfiller activities (HR task, HR service, catalog item, flow), notifications, flows, content, activity containers, and pulse surveys.
Audience (HR criteria) decides which activity sets and activities apply to a given subject (e.g., only US employees, only a given department), and the activity set trigger type (Immediate, Date, Other activity sets, Condition, Combination, Advanced) decides when a set starts.

You can attach an HR service to a lifecycle event so the LE produces cases, and you can use the Test Activity Sets tool to dry-run which activities would fire for a sample employee before going live. The Performance Improvement Plan (PIP) is delivered as a lifecycle event.

Employee Files, Document Templates, and Document Generation

Document Templates generate populated documents (offer letters, confirmations) from data on the record. Template types include HTML templates and PDF (Advanced forms) templates; PDF/advanced forms support fillable fields and signature flows.
HR document generation runs a template against a case/profile to produce a document that an agent can edit before sending.
Employee Document Management stores employee-related documents in secure storage (the "employee file"). Each document has a document type, and the security policies on the document type control who can access it.
E-signature is integrated via DocuSign and Adobe Acrobat Sign services.

HR Service Portal and Employee Center

Employee Center (and the unified Employee Center Pro) is the current cross-departmental employee portal that replaced the older standalone HR Service Portal. Key concepts:

User criteria control who can see a catalog item, category, knowledge base, quick link, or portal content. User criteria match on attributes such as role, group, department, location, or company. A piece of content can have "Available for" criteria (grant) and "Not available for" criteria (deny); deny wins.
Taxonomy / topics organize content into browsable categories on the portal.
Employee Center surfaces the HR catalog, knowledge, Virtual Agent, requests/case status, and journey content. Personas/roles determine what each user can do in the portal.

Domain 1: HR System Architecture (36%)

This domain is about the data model, scoping, and configuration objects that make HRSD work. Most architecture questions reduce to: which scoped app owns this, which table does this extend, and which COE/criteria controls visibility?

Scoped Applications and COE Data Separation

HRSD ships as a set of scoped applications, not as part of the global scope. The foundation is the Human Resources Scoped App: Core (com.sn_hr_core), which delivers Case and Knowledge Management, with companion scoped apps for Enterprise Onboarding and Transitions (Lifecycle Events), Employee Relations, Employee Document Management, and others. Scoping isolates HR application logic and data and is why legacy (non-scoped) HR customers must migrate HR data from non-scoped to scoped to adopt new features.

Centers of Excellence (COEs) are the organizing principle for data separation in HRSD. A COE is a functional HR discipline; the Zurich COE data model lists Employee Relations, Lifecycle Events, Payroll, Talent Management, Workforce Administration, Total Rewards, and HRIT Operations, plus Benefits, Compensation, Corporate Communications, and Global Mobility, which are inactive by default. Each COE has:

its own case table that extends the base HR case table,
its own HR services (the HR service COE decides which case table a case lands in),
optionally an active COE security policy that limits its cases to listed groups.

Separation is not automatic: the HR case reader and writer roles cover all HR cases. Because each COE has its own case table, an active COE security policy can restrict a COE (for example Payroll) to specific groups, and Employee Relations adds case restriction configurations so that agents outside the permitted groups cannot read restricted ER cases even with case reader or writer roles. HR knowledge is secured per knowledge base by user criteria, not by COE.

HR Table Structure (`sn_hr_core_*`)

The HRSD data model is built on the platform Task [task] table:

The base HR case table (in the core scope, prefixed sn_hr_core_) extends Task [task], inheriting state, assignment, work notes, SLAs, and approvals.
Each COE case table extends the base HR case table (e.g., a Benefits case table, a payroll case table). This is classic table inheritance: child tables add COE-specific fields while sharing common case behavior.
HR task records also extend Task and hang off a parent HR case.
The HR Profile (sn_hr_core_profile, also surfaced as the Employee Profile) is a per-person record that references the platform User [sys_user] record and stores HR-relevant attributes; profile fields can be secured individually, and tax-identification fields support encryption. (UNVERIFIED: exact current table name sn_hr_core_profile vs. the newer Employee Profile table name varies by release; confirm against the HR Profile / Employee Profile docs for your target release.)
Supporting configuration tables include HR service, HR service categorization (COE, topic category, topic detail), HR criteria, assignment rules, matching rules, and the HR skill tables.

Because HR cases extend Task, platform features (SLAs, workflow/Flow Designer, Agent Workspace, approvals) apply, but HR adds its own security layer on top so that Task-level access does not automatically grant HR case access.

HR Criteria, Conditions, Assignment and Matching Rules

HR criteria are reusable condition definitions evaluated against a subject (usually the employee/profile or the case). They drive which HR services an agent can request for a subject person, which lifecycle activities apply, which Employee Center content is shown, which document template is used, and similar conditional behavior. HR criteria are distinct from catalog user criteria: user criteria on the HR catalog item control which employees can see and request it, and user criteria can be created from an HR criteria record.
Conditions on services and producers further refine eligibility.
Assignment rules automatically set the assignment group/assignee on an HR case based on conditions (COE, location, service, etc.). Matching rules narrow assignment to agents who hold the required HR skills. Advanced Work Assignment (AWA) can push HR work to agents via queues instead of static groups. Test tooling exists to validate assignment rules before activation.
Client roles / client role assignment rules automatically grant or revoke roles to users based on conditions, used to keep portal/agent access in sync with org data.

Configuration vs. Customization

HRSD is designed to be configured (services, criteria, templates, activity sets, COEs) rather than customized in code. Guided Setup walks an implementer through the core configuration. Prefer Flow Designer over legacy workflow for new automation.

Domain 4: Platform, Role, and Contextual Security (16%)

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 example sn_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.

Domain 3: ServiceNow Implementation Methodology (7%)

Smallest domain, but easy points if you know the framework names.

Now Create (formerly NowCreate) is ServiceNow's official, prescriptive implementation methodology: a curated library of leading practices, role-based guidance, project plans, templates, and tools drawn from many successful implementations. It is delivered as Success Packs scoped to a product or outcome (there is HRSD-specific guidance).

Now Create is commonly described as a phased, hybrid-waterfall delivery model. Across ServiceNow's published material the phases are presented as Initiate, Plan, Execute, Deliver, and Close (some material adds a Get Started phase before Initiate), executed across parallel workstreams (Value Management & Analytics, Project & Program Management, Architecture & Technical Governance, Design/Build/Unit Test, Testing, Organizational Change Management, Support). (UNVERIFIED: ServiceNow periodically relabels phases and workstreams; treat the exact phase list as approximate and verify on the current Now Create site for your exam release.)

For HRSD specifically, expect questions on: using Guided Setup, configuring rather than customizing, planning COE and data-model decisions early, migrating from legacy/non-scoped HR, and organizational change management for a portal rollout.

Fast-recall cheat list

Weights: Core HR Apps & Portal 41% · HR System Architecture 36% · Platform/Role/Contextual Security 16% · Implementation Methodology 7%. Exam: 45 questions / 90 min.
HR service = configuration/definition; HR case = the live work record created from it.
Record producer turns a catalog form submission into an HR case (maps variables → case fields).
HRSD is scoped: core scope is com.sn_hr_core; legacy HR must migrate non-scoped → scoped.
COE = Center of Excellence: each COE has its own case table (extending sn_hr_core_case) and HR services; access is narrowed only by active COE security policies (and ER case restrictions).
Table inheritance: base HR case extends Task [task]; each COE case table extends the base HR case table; HR tasks extend Task.
HR Profile ties HR data to sys_user; fields can be secured/encrypted (tax IDs).
Lifecycle Event → Activity Set (phase) → Activity (step); audience (HR criteria) decides what applies and trigger types decide when; Test Activity Sets validates before launch. PIP is an LE.
HR criteria gate service/activity/form eligibility; catalog user criteria gate portal/catalog visibility (deny beats allow).
Assignment rules set group/assignee; matching rules require HR skills; AWA routes via queues.
Document Templates: HTML and PDF (Advanced forms); e-sign via DocuSign / Adobe Acrobat Sign; documents stored via Employee Document Management.
Employee Center (Pro) replaced the standalone HR Service Portal as the unified employee portal.
Security layers stack: Platform ACL + HR role + COE/contextual security all must pass. Employee Relations is the most restricted COE (case restrictions + COE security policy).
Now Create = official implementation methodology, Success Packs, phased + workstreams. Use Guided Setup; configure, don't customize.