ServiceNow HR Case Management Use Cases for Enterprise Teams

HR Case Management in enterprises

The use cases below are the ones enterprise HR teams most often run through HR Case Management: time-off and absence, workplace accommodation, policy clarification and grievances, compensation and benefits review, learning programmes, and role changes. For each, the page sets out who benefits, which platform capability does the work and what must be in place first, then compares them by trigger, risk and signal, and shows how to choose the first one and when a use case should wait.

Use case: Time-off and absence management

Employees submit requests for vacation, sick leave, or unpaid time off. HR reviews against policies (accrual balances, approval authority), approves or denies, and notifies the employee and manager. Cases track the complete lifecycle: request, approval, communication, and resolution.

Who benefits: employees get fast decisions and clear communication, managers see approved time in the system, HR has accurate records for payroll and reporting.

Platform capability involved: workflow routing (to the right approval authority), integration with leave accrual systems (to check balances), notifications to multiple stakeholders.

Prerequisites: leave system configured with accrual rules, managers and HR trained on approval process, integration set up to sync decisions back to payroll.

Use case: Workplace accommodation requests

An employee needs workplace accommodation due to a disability or medical condition. They submit a case describing the need. HR triages it, may request medical documentation, engages with the employee and relevant departments (facilities, IT), and agrees on accommodation. The case documents decisions and timelines for compliance.

Who benefits: employees have a structured process and clear timeline, HR has documented decisions for legal protection, the company complies with disability regulations.

Platform capability involved: document management (attachment of medical forms or evidence), case escalation (complex cases go to legal or HR leadership), conditional routing (some cases need medical review, others go straight to HR operations).

Prerequisites: policy and procedures documented, HR trained on accommodation process and regulatory requirements, integration with relevant departments (so they see accommodation requests they need to handle).

Use case: Policy clarification and grievances

An employee has a question about a policy (compensation, benefits, code of conduct) or feels treated unfairly and submits a case. HR handles the inquiry or escalates to management or legal depending on severity. Cases create an audit trail for potential disputes.

Who benefits: employees get authoritative answers and feel heard, HR documents decisions, legal/compliance has evidence of fair handling if disputes arise later.

Platform capability involved: knowledge integration (link to relevant policy documents in the case), escalation workflows (serious allegations go to management or legal), multi-team collaboration (HR, legal, management all add input).

Prerequisites: policies documented and accessible, escalation criteria clear (which issues go to legal, which to management), training for HR on documentation and evidence collection.

Use case: Compensation and benefits review

During annual compensation review cycles, HR manages cases for salary reviews, promotion approvals, and bonus allocations. Managers submit cases for their direct reports, HR coordinates with compensation and legal, and decisions are communicated back through cases. The case documents the decision, the reasoning, and any appeals.

Who benefits: managers have a structured process, HR coordinates consistently across the company, legal has documentation, employees have a clear channel for questions or appeals.

Platform capability involved: role-based forms (different questions for promotion vs. salary review), conditional routing (large raises need executive approval, external hires follow different rules), integration with payroll (approved decisions sync to payroll).

Prerequisites: compensation policies defined, approval authorities clear (who approves what), manager training on the process, integration with payroll set up to apply decisions.

Use case: Learning and development programs

Employees nominate themselves or are nominated for training, development programs, or mentoring. HR manages the case: reviews eligibility, coordinates with training providers or mentors, tracks completion, and documents learning outcomes. Cases create a record of development activity for career planning and succession planning.

Who benefits: employees have a clear process for accessing learning, managers can see their team’s learning activity, HR can report on company-wide learning trends.

Platform capability involved: eligibility rules (who can access what programs), cost tracking (programs have costs that need approval), integration with learning management systems (to track completion), and reporting (learning trends by team and individual).

Prerequisites: learning programs defined with eligibility criteria and costs, training providers identified or integrated, managers trained to support employee learning.

Use case: Role changes and internal mobility

An employee applies for an internal role or is nominated for promotion. HR manages the case: coordinates with the hiring manager, processes approvals (including compensation review), handles background checks if needed, and documents the decision. The case tracks the complete transition including knowledge transfer or exit from the old role.

Who benefits: employees see a structured, fair process for advancement, managers get candidates already vetted by HR, the company retains talent and builds succession plans.

Platform capability involved: job matching (recommend suitable candidates), approval workflows (functional approval, compensation approval, executive sign-off), integration with onboarding (transition the employee to the new role and team).

Prerequisites: job descriptions current and available, compensation bands defined, approval authorities clear, integration with onboarding systems to handle role transition.

Prerequisites for successful HR case management

Clear policies and procedures: cases enforce policies, so policies must be well-defined and accessible. Ambiguous policies lead to inconsistent case handling and disputes.

Manager and HR training: users need to understand the process, what documentation is required, and timelines. Training on the system itself is secondary to training on the processes.

Integrations: most use cases require integration with other systems (payroll, learning management, leave accrual). Plan integrations as part of implementation.

Governance: define escalation criteria (when does a case go to management or legal), approval authorities (who can approve what), and review cycles (who reviews case handling and compliance).

Choosing the first use case by what it proves

Enterprise HR teams often have a long list of possible use cases, and the instinct is to start with the one that most people complain about. That is often the hardest one. A better first use case is one whose outcome is easy to check, whose approvers are few and whose failure would be visible without causing harm. Choose the case that lets the team prove the mechanics, such as routing, approval and notification, before it takes on the judgment-heavy work.

Use cases compared by trigger, risk and signal

The table compares common enterprise use cases on what starts them, the main risk and the signal that tells you the adoption is working. Use it to order the backlog rather than to decide the answer for each team.

A readiness check before adopting any use case

1. Write the policy the case enforces in one paragraph, and check that the paragraph is current.
2. Name the approver for each decision the case requires, and confirm they accept the role.
3. List the systems the case must read from or write to, and mark which of them are live.
4. Identify the employees most likely to be affected and ask them what they would expect to see.
5. Decide the escalation rule, then test it with one case that is deliberately difficult.

When a use case should wait

Some use cases are not ready even when the demand is clear. A use case should wait when its policy is being rewritten, when the approvers it needs have not been appointed, or when the data it depends on is known to be unreliable. Starting anyway tends to produce a fast launch followed by a slow, expensive correction. The request fulfilment intake note covers building a clear intake path for requests.

A pay review use case launched before compensation bands are agreed is a useful warning. Managers may submit cases using their own judgment, and the first review cycle can produce decisions that cannot be defended side by side. The use case itself may be sound; its timing is the problem.

How the use cases connect

Several of these use cases share the same feeds and the same approvers, so a decision on one changes the others. Onboarding and role changes both need the employee record to be accurate, and the employee onboarding workflow design note covers how onboarding work is designed around roles. The requirements workshop questions are the place to settle the eligibility and confidentiality rules that development and accommodation cases both depend on, so settle those before either goes live.

Should every employee be able to start any use case?

No. Start rights should follow the policy. A development nomination may be open to a manager only, while a time-off request is open to every employee. Write the start rule for each use case.

When should a use case be formally closed?

When its requests stop arriving, when the policy it enforces has been withdrawn, or when a newer route handles the same need. Close it formally so employees are not left with a dead form.

Can one use case cover several policies?

It can, but then the decision rules become harder to explain. If a single form must branch into three policies, it is often clearer to split it.

What feedback should employees give on a use case?

Ask whether they knew where to start, whether they understood what was decided and whether they knew what to do next. Those three answers show more than satisfaction scores do.

HR cases versus HR service requests: which one to open for a given need

Open an HR case when the matter will involve several people, several decisions, or a record that must show how the outcome was reached. Use a plain service request when one person needs one thing done against a fixed set of steps. In most implementations, the difference shows up early in use: teams that send every question into cases end up with long queues of simple requests, and teams that send disputes into service requests lose the trail when a decision is challenged.

A useful test is to ask three questions before routing. Will more than one team add input before the outcome is known? Could the decision be challenged later, so the reasoning has to be recorded? Does the outcome depend on judgement rather than on a rule that can be applied the same way each time? If the answer to two of these is yes, the matter belongs in a case. Start with the HR case management overview if the case types are not yet defined.

Mixed cases cause most of the friction. A time-off request usually starts as a service request because the rule is fixed, but it becomes a case when the employee disputes a balance or an absence overlaps a medical leave decision. Build the handoff into the design rather than leaving it to the agent: the request should convert into a case with its history attached, not restart from zero. Teams that skip this find the same employee explaining their situation twice.

Keep the routing rule short enough to fit on one screen, and review it after the first quarter. The common mistake is to write the rule around the platform’s categories rather than around the questions employees actually ask. Start from the ten most frequent requests in the last quarter, sort each one by the three tests above, and only then build the routing. Most of the work is in the sorting, and the HR case and knowledge design work covers the build once the types are agreed.

How one HR case moves from first message to recorded outcome

An HR case is one record that holds a single matter from the first request to the final decision, along with every input that shaped it. In practice the record is only useful when someone can read it cold months later and see who said what, which rule applied, and why the outcome was reached. The walk-through below follows one common example, a disputed carry-over balance on a time-off request, because it touches most of the steps that other examples skip.

The case opens when the employee submits the matter with the facts stated once: the dates, the balance they expected, and the document they are relying on. Teams that let employees type a free-text summary and nothing else usually spend the first review chasing those basics, so the form should ask for them directly. For the intake side, see HRSD employee workflows.

Triage comes next. Someone in HR confirms the matter really needs a case, sets the priority, and names the person who owns the decision. Deciding those owners before go-live is part of the HR case and knowledge design work. Teams often skip this step, and the result is a case that sits in a shared queue while two people each assume the other has it.

Then the case collects inputs. The payroll team confirms the carry-over balance, the manager confirms whether the absence was agreed, and HR checks the accrual rule. Each reply is added to the case rather than sent by email, so the reasoning stays with the record.

The decision is recorded with its reason in one sentence, not just its outcome. A line such as “balance carried over under the accrual rule in force on the request date” is far more useful later than “approved”. Then the employee is told the outcome in the case itself, and the case is closed only after the follow-up, such as a payroll correction, is confirmed.

• Opened: facts stated once, with supporting document attached
• Triaged: owner named, priority set, next review date written on the record
• Gathering input: each contributor adds a dated note to the record
• Decided: outcome and one-sentence reason recorded
• Closed: follow-up actions confirmed, then the case is closed

The common mistake is closing at the decision. A case that closes when the approval is clicked, before the payroll correction lands, is the record that gets reopened in a dispute. Check the follow-up before the case is closed. For the wider set of HR case types, start from the ServiceNow HR Case Management guides.