ServiceNow HR Case Management Best Practices

HR case management is the way an HR team tracks employee requests and HR matters as cases, each with a defined type, approvers, service levels and an audit trail. This page sets out eight design practices for it and a weekly routine for running the case queue.

Practice 1: Define and Document Your Case Types

Before implementing, identify which HR work will flow through cases. List case types: employment verification, return-to-work, dispute resolution, investigation, severance, contingent worker onboarding. For each type, document the workflow: who should approve, what information is required, how long should it take? This becomes your case type configuration. Do not try to make one generic case type handle everything; specialized types with tailored workflows are faster and clearer than trying to route everything through one universal process. Each case type should have clear entry criteria: what triggers creation? And clear exit criteria: what constitutes completion?

Practice 2: Implement Role-Based Access and Approval Authority

Assign case permissions based on role, not individual. An HR Specialist can create and edit cases, can assign cases to others, but cannot approve compensation changes—only an HR Manager can. A manager can approve their own team’s requests but cannot approve requests from other teams. This segregation prevents errors and ensures the right person makes each decision. Document your approval matrix: who can approve what, at what threshold? A case involving a significant salary change might require HR Director approval; smaller salary adjustments can be approved by an HR Manager. Clear authority levels prevent cases from stalling when an expected approver is unavailable.

Practice 3: Establish Realistic SLAs and Monitor Them

For each case type, define a target completion time that fits the work involved: a simple verification should be much faster than an investigation. These become your SLAs. Do not set SLAs you cannot meet; an SLA you miss is demoralizing. Communicate SLAs to employees with the committed time for their case type. Monitor SLA compliance weekly. If you miss SLAs consistently, increase the SLA target or add staffing. Use SLA breaches as a prompt to fix the bottleneck: if cases consistently stall awaiting a particular approval, that approver may be overloaded or unclear on their responsibility.

Practice 4: Automate Routine Decisions and Steps

When a case type requires the same decision every time, automate it. An employment verification request always triggers the same step: look up the employee in the HR system, confirm employment dates, and generate a verification letter. Automate this step to reduce manual work and improve consistency. Automation is safe when decision criteria are clear and binary. A case requiring judgment—is this leave request reasonable?—should not be automated.

Practice 5: Create Comprehensive Audit Trails

Every case should record who did what, when, and why. Configure case workflows to capture this automatically. When an approval happens, record the approver, date, and any comments they leave. If a case is reassigned, record who reassigned it and why. Maintain activity history: every state change, every field update, every comment must be visible and immutable. This audit trail is your evidence of due process if an employee disputes a decision. Make audit trails visible to authorized staff but hidden from the employee (mark sensitive decisions as internal comments if needed).

Practice 6: Enable Transparency for Employees and Managers

Employees want to know status of their cases. Provide a portal where they can see their open cases, current status, and estimated completion date. For sensitive matters, you can limit visible details: show status but not the content of internal comments. Managers want to see all cases from their team. Provide a manager dashboard showing cases awaiting their approval, cases in progress, and aging cases requiring follow-up. Transparency builds trust and reduces status inquiry emails.

Practice 7: Integrate with HR System of Record

HR Case Management should read from and write to your HR system (SAP, Workday, or another HR Information System). When a case is resolved, update the HR system automatically. An employment verification case, when closed, should flag the employee record as “verification completed”. A return-to-work case, when closed, should update leave balance and reinstate the employee. This prevents work from being done in the case system but not reflected in official records. It also prevents duplicate work: if the HR system already has current employment dates, the case system can retrieve them rather than asking the employee to provide them again.

Practice 8: Conduct Regular Case Reviews and Adjust Processes

Review cases monthly. Which case types take longer than planned? Which approvers are bottlenecks? Which cases are most frequently escalated? Use this data to improve: if return-to-work cases take 10 days but your SLA is 5 days, either increase the SLA or add steps that can run in parallel instead of sequential. If one approver blocks many cases, add another approver to share the load or clarify the approval criteria so more cases can be approved without escalation. Process improvement is continuous, based on data, not hunches.

Running the case queue week to week

A well-designed case model can still deteriorate within a quarter if nobody runs the queue with a routine. The design sets the rules; the weekly rhythm is what keeps stalled matters from aging out of sight. This section is aimed at the case queue lead and the HR operations manager who own the day-to-day flow, and it covers the practices that sit between the design work and the periodic reviews described elsewhere in this library.

Set a standing review of aging cases

Aging cases are the ones that have stopped moving without anyone deciding to stop them. A short standing review, held at the same time each week, is the simplest defense. Sort open cases by how long they have been waiting in their current state, not by their total age, because a case that has sat at one approver for a long time needs a different response from one that is simply in progress. For each case past the point where the team would expect it to move, the reviewer should record a single next action and a named owner. A review that ends without owners assigned is a meeting, not a control.

Write a closure standard for each case type

Teams often agree that a case is closed when the work is done, but leave the meaning of done to individual judgment. A closure standard turns that into a checklist for each case type. It should state the outcome that must be recorded, the people who must be told, the documents that must be attached and the system updates that must have happened. Keep it short enough that a caseworker will read it at the point of closing, and review it when a case type changes. A standard that exists only in a policy document rarely changes what people do on a Thursday afternoon.

Handle the cases that span two types

Some matters start as one type and turn into another. A complaint about a manager may reveal a pay issue, or a leave request may uncover a grievance. The wrong response is to keep the original case open and quietly add work to it, because that hides the second matter from its own process and its own service level. The better response is to close or link the original case with a reason, then open the second case with a reference to the first. Agree the rule for doing this in advance, so that caseworkers do not improvise it under pressure.

1. Record the reason the matter changed type, in one sentence, on the original case.
2. Open the new case with the reference to the original, and carry across only the facts that the new process needs.
3. Confirm that the employee knows which case is now active and who owns it.
4. Check whether the original case’s visibility rules still suit the new matter, since a more sensitive matter may need tighter access.

Use the queue to find the process problem, not just the caseworker problem

When a caseworker is consistently behind, the first assumption is capacity or skill. Look first at the work itself. If the same kind of case regularly comes back from the same stage, the problem is probably in the request form, the routing or the decision criteria, and extra training will not fix it. Keep a short note of recurring returns, and bring the most common ones to the review that updates the design. Improvement that comes from the queue is often cheaper than improvement that comes from a separate project.

Operating questions for case queue leads

How many cases should one caseworker hold at once?

There is no universal number. The right load depends on how many cases are waiting on the employee compared with those that need the caseworker’s own action, and on how complex the case types are. Watch the proportion of cases a caseworker has touched in the last week. If most of their queue is waiting on others, their load is not the problem, and a higher count may be sustainable.

Should leadership see the weekly review output?

A short summary is useful for leadership, covering the cases at risk and the decisions that are waiting on them. The full queue is an operating tool and should stay with the people who work it, because a long list shared upward tends to produce pressure rather than action.

What do we do when a caseworker leaves with open matters?

Reassign each open case in the platform during the handover, with a note on its current state and next step. Cases that were assigned to a person rather than a queue are the ones most often missed, so check for them specifically before the person’s last day.

Next step for queue operations

Have a description of your case types and the states where cases most often stop ready. The roles, responsibilities and RACI guide covers who owns each decision in the queue, the enterprise use cases guide covers specific use cases for HR case management, and the continuous improvement page covers ongoing improvement of a platform as it changes.