ServiceNow HR Service Delivery: A Developer's Guide to the Employee Lifecycle
When ServiceNow released HR Service Delivery, many developers treated it like any other ITSM module — create a catalog item, route it to an HR group, done. That's selling it short. HR Service Delivery is built around the employee lifecycle: a structured sequence of stages from the moment someone is hired to the day they leave. Getting it right means understanding the data model, the case lifecycle, and where developer scripting adds real value.
The Core Data Model: More Than Just Cases
The most important table in HR Service Delivery is hr_profile. Every employee, contractor, or contingent worker has exactly one hr_profile record. It's the identity anchor — HR cases, onboarding tasks, profile updates, and compliance records all link back to it.
Key hr_profile fields:
user_id— links to the sys_user record (when an account exists)department_id,job_title,manager— organizational contexthr_service_type— distinguishes employee types (full-time, part-time, contractor)state— active, inactive, on_leave
hr_case is where the lifecycle stages live. Each case represents a lifecycle event — onboarding a new hire, processing a promotion, handling a relocation, managing an offboarding. Cases are created programmatically (from an HR playbook) or by employees via the portal. Critically, hr_case extends task, so it inherits all the assignment, work notes, and SLA machinery you'd expect.
hr_task sits one level deeper. A single hr_case (say, "New Hire Onboarding") might spawn multiple hr_task records: provisioning a laptop, setting up payroll, running a background check, assigning a mentor. Tasks are what HR agents actually work on day-to-day.
Onboarding: Where the Lifecycle Starts
Good onboarding is where HR Service Delivery pays off most visibly. The pattern that works:
- An HR recruiter creates an
hr_caseof typeonboardingfrom a playbook template. - The case triggers a Flow Designer flow that auto-populates tasks based on the employee's role and location.
- Each task is assigned to the appropriate team: IT gets hardware provisioning, Facilities gets desk assignment, HR runs the compliance checklist.
Here's a script-include pattern for generating onboarding tasks from a template, which many teams use instead of relying solely on Flow Designer:
var OnboardingTaskGenerator = Class.create();
OnboardingTaskGenerator.prototype = {
initialize: function(grCase) {
this.hrCase = grCase;
},
generateTasks: function() {
var templateTasks = [
{ short_description: 'Provision laptop', assignment_group: 'IT Hardware', due_offset_days: 3 },
{ short_description: 'Create email account', assignment_group: 'IT Systems', due_offset_days: 1 },
{ short_description: 'Run background check', assignment_group: 'HR Compliance', due_offset_days: 5 },
{ short_description: 'Schedule orientation', assignment_group: 'HR Operations', due_offset_days: 7 }
];
var grProfile = new GlideRecord('hr_profile');
if (!grProfile.get(this.hrCase.hr_profile)) return;
templateTasks.forEach(function(task) {
var grTask = new GlideRecord('hr_task');
grTask.initialize();
grTask.hr_case = this.hrCase.sys_id;
grTask.short_description = task.short_description;
grTask.description = 'Auto-generated onboarding task for ' + grProfile.full_name;
grTask.assignment_group = task.assignment_group;
grTask.state = 1; // Open
grTask.insert();
}.bind(this));
},
type: 'OnboardingTaskGenerator'
};
Call this from a Before Insert business rule on hr_case when the type is onboarding. The offset-based due dates keep things moving without hardcoding calendar dates.
Offboarding: The Critical Half of the Lifecycle
Onboarding gets all the attention. Offboarding is where most organizations have gaps — and those gaps are security risks. When an employee leaves, you need:
- Account deactivation (Active Directory, Azure AD, SaaS apps)
- Hardware return and asset reconciliation
- Knowledge transfer tasks
- Final payroll processing
The pattern mirrors onboarding but with a stronger dependency chain. Your offboarding flow should parallelize what can run concurrently (badge deactivation, email forwarding, asset tag check) and serialize what must happen first (data backup before account lock).
Use Integration Hub or a scripted REST step to call your identity provider's API when the offboarding case state moves to "In Progress." Don't wait for a human to remember.
Employee Center: The Modern HR Portal
If you're still on the classic HR Service Portal, the Employee Center is worth evaluating. It surfaces content from multiple service domains (HR, IT, Facilities) under a single interface, using hr_profile as the unified identity. Employees see one dashboard with their open cases, pending tasks, and company announcements.
From a developer standpoint, Employee Center uses Connect Topics and Hero Actions — configurable tiles that link catalog items or articles to specific profiles. You can extend these with a simple catalog client script or by contributing to the sn_hr_core module's angular widgets.
Developer Gotchas
A few things that trip people up:
HR cases don't use the approval framework the same way. Approval stages on an hr_case are handled through the sysapproval_approver table just like ITSM, but the routing logic is driven by the HR definition/activity model, not standard approval workflows. Don't try to force a standard approval flow onto an HR case — use the HR activity framework instead.
Cross-scope access requires grants. If you're building a scoped app that reads hr_profile, you'll need to add read grants on the hr_profile table to your application. HR Service Delivery tables are not automatically accessible to scoped apps.
Audit everything. HR records are sensitive. Any custom script that reads hr_case or hr_profile should log to the activity table. Don't bypass the sys_audit trail for convenience — compliance teams will ask.
State transitions are event-driven. Moving an hr_case from open to in_progress to closed fires .before and .after business rules. If you're writing async business rules on HR cases, be aware of the order of operations — especially around profile state changes that cascade to user account status.
Where This Fits in the Now Platform
HR Service Delivery connects naturally with other ServiceNow products: Virtual Agent handles common HR FAQs ("how do I update my bank details?", "what's our parental leave policy?"), HR Performance Management ties onboarding tasks to 30/60/90-day check-ins, and ITOM integration can trigger hardware-related cases automatically when a new server is provisioned for a new hire.
The platform's strength is that these aren't separate silos — they're tables that reference each other through cmdb_ci, hr_profile, and sys_user. Understanding those relationships is what separates a basic HR ticketing setup from a lifecycle-aware employee experience platform.
Start with the data model. Get the hr_profile right. Everything else follows.