CIS-HRSD Study Guide: HR Service Delivery Without the Mystery
Who the CIS-HRSD exam is really for, how the COE data model works, why HR security is its own animal, and a six week study plan with hands-on PDI labs.
Of all the implementation specialist exams, HR Service Delivery is the one where general platform experience helps you the least. I've watched strong ITSM consultants walk into their first HRSD project, open a list of HR cases, see nothing, and assume the instance is broken. It isn't. It's working exactly as designed, and understanding why it's designed that way is most of what this exam tests.
So who is CIS-HRSD for? Three groups, in my experience. Platform admins and consultants who want into employee workflow projects, which is where a lot of the interesting work is right now. HRIT analysts who already live in Workday or SuccessFactors and want to own the service delivery layer. And partner consultants who need the credential to get staffed, because customers ask for it by name.
The honest value: this cert carries more weight than most CIS exams precisely because fewer people hold it, and because HRSD projects fail in ways ITSM projects don't. Nobody gets fired over a misrouted incident. Leak one employee relations case to the wrong audience and you have a legal problem. The cert alone won't make you an implementer, but preparing for it properly will force you to learn the two or three things that separate people who configure HRSD from people who break it.
The exam at a glance
The blueprint moves around a bit between releases, but the shape has been stable for years. Expect something close to this:
| Domain | Approximate weight |
|---|---|
| HRSD overview, architecture, and data model | 10% |
| Core configuration: HR profiles, security, roles, HR criteria | 20% |
| HR services and case management | 30% |
| Lifecycle events and journeys | 15% |
| Employee Center, knowledge, and documents | 15% |
| Integrations, migration, and go-live practices | 10% |
The exam runs around 60 questions in 90 minutes, multiple choice, proctored online or at a test center through Now Learning. Treat all of those numbers as approximate: check the current exam blueprint on Now Learning before you book, because question counts, weights, and pricing drift between releases.
ServiceNow publishes delta exams each release to keep certifications current. Passing CIS-HRSD once is not a lifetime pass; budget an hour or two per release for the delta.
Before you start
CSA comes first. The Certified System Administrator exam is the prerequisite for every CIS track, HRSD included. If you haven't passed it, stop reading this and go do that. The HRSD exam assumes you already know what a table, an ACL, a business rule, and a catalog item are, and it will not slow down to explain them.
Take the implementation course. The official learning path expects the HR Service Delivery Implementation course, and the exam questions are noticeably aligned to its material. Check Now Learning for the current path and any mandatory course requirements.
Get HRSD on a PDI. Request a personal developer instance and activate the HR Service Delivery plugins with demo data. The demo data matters: it gives you populated COEs, sample HR services, a working Employee Center, and lifecycle events you can dissect. Every lab in this guide assumes you have it.
You do not need an HR background. You do need to accept, early, that HRSD will refuse to behave like the ITSM apps you know, and that this is a feature.
The concepts that actually matter
HRSD is case management, not an HRIS
This is the first mental model to get right, and the exam probes it from several angles. HRSD does not want to be your system of record for employee data. Workday, SuccessFactors, or whatever HRIS the customer runs keeps that job: it owns the hire date, the salary, the org assignment, the termination. HRSD sits on top as the service delivery layer: the place where an employee asks a question, requests a letter, reports a payroll discrepancy, or gets walked through onboarding.
The bridge between the two worlds is the HR profile, stored on sn_hr_core_profile. Every employee who can be the subject of an HR case gets one. It caches the slice of HRIS data that HRSD needs to route and secure work: employment type, location, department, position. Data flows in from the HRIS through IntegrationHub spokes (there are prebuilt spokes for the major HRIS platforms) or through scheduled imports. Data does not master here.
If you find yourself building forms to edit salary data in ServiceNow, you have taken a wrong turn somewhere.
The COE model
HRSD organizes everything around Centers of Excellence, or COEs. A COE is a functional area of HR: payroll, benefits, employee relations, and so on. Each COE gets its own scoped case table extending the core HR case, its own roles, and its own slice of the service taxonomy.
Here's the family tree you need to know cold. The parent extends task, like every other case table on the platform, and the COEs extend the parent:
task
└── sn_hr_core_case (HR case, the parent)
├── sn_hr_core_case_payroll (Payroll)
├── sn_hr_core_case_benefits (Benefits)
├── sn_hr_core_case_relations (Employee Relations)
├── sn_hr_core_case_talent_management (Talent Management)
└── sn_hr_core_case_total_rewards (Total Rewards)
There are more in a real instance (Workforce Administration and HR Operations show up with demo data), but these are the ones the exam loves. Why does the structure matter? Two reasons. Security: because each COE is its own table, access can be granted per COE. A payroll agent can work payroll cases without ever seeing an employee relations case about their own manager. Reporting and taxonomy: cases roll up cleanly by function, and HR services map onto COEs one to one.
The exam will test whether you know that HR cases extend task (not incident, not sn_customerservice_case), and whether you understand that choosing a COE for a service is a security decision, not just a filing decision.
HR security is its own animal
On my first HRSD project the customer's platform admin filed a defect: "admin cannot see HR cases." I got to write my favorite ever defect response: working as intended.
HRSD lives in scoped applications, and the scoped tables do not honor the platform roles you're used to. The itil role means nothing here. Even admin gets no automatic access to HR case data; HR grants its own access through its own role hierarchy. The core roles to know: sn_hr_core.basic is the entry point for anyone working in HR tools, sn_hr_core.case_reader and sn_hr_core.case_writer do what they say, sn_hr_core.manager adds queue oversight, and sn_hr_core.admin administers the HR application itself, which is deliberately not the same thing as platform admin. On top of that, COE-specific roles gate the individual case tables.
Why so strict? Because HR data is legally sensitive in a way IT data is not. Disciplinary cases, medical accommodations, compensation disputes: the platform team must not be able to browse these. When you design HRSD security you are not just preventing accidents, you are building the separation that lets an HR director sign off on the system at all.
HR criteria vs user criteria
Here it is: the single most tested distinction on this exam, and the one I've seen trip up experienced admins on real projects.
User criteria is the platform-wide mechanism you already know from CSA. It gates knowledge bases and catalog items, and it matches on things like user, role, group, company, and location. It answers "can this user see this content?"
HR criteria is an HRSD-specific mechanism. It defines an audience of employees using conditions on the user record and, crucially, the HR profile: employment type, HR position, location, department. HR criteria answer "which employees does this HR thing apply to?" and they gate HR services (who can request parental leave), lifecycle event audiences (which activities fire for a US hire vs a UK hire), targeted content in Employee Center, and document templates.
The two look similar, live in different places, and are absolutely not interchangeable. A knowledge base is still secured with user criteria even when it's an HR knowledge base. An HR service is gated with HR criteria, full stop.
If a question is about who can request an HR service or who is in a lifecycle event audience, the answer involves HR criteria. If it's about who can read a knowledge base or catalog item, it's user criteria. Drill this until it's reflexive, it is worth multiple questions.
HR services and the HR case lifecycle
An HR service is the unit of configuration that ties the whole product together. One HR service record defines: which COE and case type a request creates, where it sits in the topic taxonomy (topic category and topic detail), which record producer collects the request in Employee Center, what fulfillment instructions guide the agent, and whether fulfillment is a standard service activity or a full lifecycle event.
The trap for platform people: you do not hand-build catalog items for HR requests. The HR service configuration owns and generates the record producer. If you catch yourself in the standard catalog editor wiring an HR form to a case table by hand, back up: create or modify the HR service, and let it manage the catalog artifact.
Once a case exists, it moves through a lifecycle that the exam expects you to know as a sequence:
Two details worth committing to memory. First, matching rules are the HRSD-flavored assignment mechanism, and they can weigh agent skills; plain assignment rules still exist underneath. Second, fulfillment instructions are agent-facing guidance attached via the service, which is how one generic "HR inquiry" agent can competently work fifty different request types.
Lifecycle events and enterprise onboarding
Lifecycle events are where HRSD stops being a ticketing tool and starts being an orchestration engine. Onboarding, offboarding, parental leave, relocation: any employee journey with multiple steps across multiple teams is a lifecycle event.
The vocabulary is the testable part. A lifecycle event definition describes the journey. It contains activity sets, which are ordered groups that fire in sequence or in parallel. Each activity set contains activities: create a task for IT, send a notification on day minus five, trigger a flow, assign a to-do to the new hire's manager. Audiences scoped by HR criteria decide which activities apply to which employees, so a US hire gets the I-9 activity and a German hire does not, all inside one definition.
Enterprise onboarding is the marquee use case, and the reason it gets its own branding is that it deliberately crosses departmental lines. One trigger fans out into HR tasks, IT requests for laptop and accounts, facilities tasks for badge and desk, finance tasks for payroll setup. The employee sees one coherent journey; behind the curtain, four departments are working their own tasks in their own queues.
Employee Center, knowledge, documents, and Manager Hub
Employee Center is the standard employee-facing portal, and it replaced the older HR-specific Service Portal. The distinction matters: the old HR portal was an HR silo; Employee Center is a unified front door where HR, IT, workplace services, and legal all publish into one experience. Content is organized by topics in a taxonomy, employees get quick links to common actions, and content delivery pushes targeted communications and campaigns to audiences, segmented, you guessed it, with criteria. If a question contrasts the legacy HR portal with Employee Center, the answer that says "unified, taxonomy-driven, cross-department" is your friend.
Knowledge in HRSD is standard platform knowledge management wearing an HR badge: HR knowledge bases secured by user criteria, article templates for consistency, and article targeting so a benefits article surfaces for the audience it applies to. The security nuance from earlier applies here in full.
Document templates round out the fulfillment story. HRSD can generate documents (an employment verification letter, an offer amendment) from templates with fields merged from the case and HR profile, then route them for e-signature through a sign document task, using either native signature capture or an integration like DocuSign or Adobe Acrobat Sign. HR criteria can control which templates apply to which employee populations.
Manager Hub deserves a glance: it's the manager-facing experience that surfaces their team's journeys, open requests, and to-dos in one place. You won't get deep questions on it, but know what it is and who it serves.
A six week study plan
Six weeks assumes you can give this five to eight focused hours a week. Compress at your own risk; the security model needs time to settle in.
Week one: foundation and setup. Refresh CSA-level platform concepts, request your PDI, activate HRSD with demo data. Spend a full session just browsing: open HR cases, look at the COE tables in the schema, click through Employee Center as an end user. Read the exam blueprint on Now Learning so you know the target.
Week two: security. Roles, scoped access, why admin sees nothing. Build the security lab below. Then spend a whole session on HR criteria vs user criteria until you can explain the difference out loud without hedging. This is the highest-yield week of the six.
Week three: HR services and case management. Build a service end to end, trace the case lifecycle, configure a matching rule. Understand what the HR service record controls versus what the record producer controls.
Week four: lifecycle events. Dissect the demo onboarding event first, then build your own small journey. Learn the definition, activity set, activity hierarchy by constructing it, not by reading about it.
Week five: the employee experience layer. Employee Center topics and quick links, knowledge bases and their user criteria, document templates with e-signature, Manager Hub, and a pass over the HRIS integration story: what the spokes do, what the HR profile caches, what stays in Workday.
Week six: consolidation. Redo the labs cold, no notes. Work through the trick patterns below. Take whatever practice assessment your learning path includes, and spend your remaining hours on whichever domain felt shakiest.
Hands-on labs on your PDI
Reading about HRSD is like reading about swimming. Here are seven labs that cover the exam's center of gravity. Do them in order.
Lab 1: install and explore. Activate the HRSD plugins with demo data. In the schema, find sn_hr_core_case and list its extensions. Open three cases from different COEs and compare the fields. Time well spent: fifteen minutes just reading the demo HR services list to see how a real taxonomy hangs together.
Lab 2: break into HR (and fail). Impersonate a user with itil and admin and try to open an HR case list. Observe the nothing. Then grant yourself sn_hr_core.basic plus sn_hr_core.case_reader and watch the doors open. Finally, check whether the case reader role shows you employee relations cases, and reason about why or why not.
Lab 3: build an HR service. Create a "tuition reimbursement" service in Total Rewards: topic category, topic detail, record producer fields, fulfillment instructions, and a checklist. Submit it through Employee Center as an employee and work it as an agent. This one lab touches a third of the blueprint.
Lab 4: criteria, side by side. Create an HR criteria record for "US full-time employees" and use it to restrict your tuition service. Then create a user criteria record and use it to restrict an HR knowledge base. Submit as different test users until you can predict every outcome before you click.
Lab 5: routing. Configure a matching rule that routes payroll cases to a payroll group based on the service, and confirm assignment happens on submission. Then break it on purpose (deactivate the rule) and watch where cases land instead.
Lab 6: a small journey. Build a lifecycle event with two activity sets: "before day one" (notification to the manager, an IT task for a laptop) and "week one" (a to-do for the new hire, a facilities task). Trigger it for a test employee and watch the activity sets fire in order. Add an HR criteria audience so one activity only applies to one location.
Lab 7: paper trail. Create a document template for an employment verification letter with merged fields from the HR profile, attach it to a service, and run the e-signature flow with a sign document task. Then add a topic and quick link in Employee Center so an employee can actually find your service.
Demo data is your answer key. Whenever your build misbehaves, find the equivalent demo record and diff your configuration against it field by field. I still do this on real projects.
How the questions try to trick you
Exam writers for CIS-HRSD have a few reliable moves. Learn to see them coming.
The criteria swap. Any question mentioning eligibility, audiences, or content targeting will offer both "HR criteria" and "user criteria" as options. Apply the rule from earlier: services and audiences take HR criteria, knowledge bases and catalog items take user criteria.
The phantom access. "An administrator cannot view HR case records. What should you do?" The wrong answers involve ACL debugging and impersonation tricks. The right answer involves granting an HR role, because scoped HR data ignores platform roles by design.
The wrong parent. Questions about the data model will offer incident or a CSM case table as the parent of HR cases. HR cases extend task through sn_hr_core_case, and COE tables extend that. Anything else is bait.
The catalog detour. Scenarios about creating a new employee request will offer "create a catalog item in the service catalog" as a plausible-sounding option. The HRSD answer is to create an HR service and let it manage the record producer.
The vocabulary shuffle. Lifecycle event questions swap "activity" and "activity set," or invent an ordering mechanism that doesn't exist. Keep the hierarchy straight: definition, then activity sets (ordered), then activities inside them.
The system of record feint. Questions imply ServiceNow should master employee data. It shouldn't. The HRIS remains the source of truth; HRSD consumes what it needs into HR profiles.
Also watch for qualifier words: "MOST likely," "BEST approach," "FIRST step." Two answers will usually be defensible; the qualifier tells you which one they want.
Exam week checklist
- Reread the current exam blueprint on Now Learning and confirm nothing shifted since you started studying.
- Redo labs 2, 4, and 6 without notes. If any feels wobbly, that's your last-day review topic.
- Skim your notes on the COE tree and the case lifecycle until you can sketch both from memory.
- Confirm your booking, and if testing online, run the proctoring system check on the actual machine and network you'll use.
- Plan your pacing: roughly 90 seconds a question. Flag anything that takes longer and come back.
- Sleep. A rested brain beats a crammed one on scenario questions, every time.
After you pass
Take the win, then do two practical things. First, set a reminder for delta exams: your cert stays current by keeping up with releases, and the deltas are short if you don't let them pile up. Second, get onto a real HRSD project in any capacity you can, because the distance between certified and useful is closed only by contact with real HR stakeholders and their very real edge cases.
From here, natural next steps are another CIS track (CSM is the closest cousin, sharing the case management DNA), CAD if you want to go deeper on building, or the broader employee experience stack: journeys, listening posts, and the Employee Center ecosystem keep growing every release. HRSD is a genuinely good specialty right now. Go be one of the people who understands why the admin can't see the cases.