OBLYTECH Logo
OBLYTECH Logo
Common ServiceNow HR Case Management Mistakes and How to Avoid Them
Home / Guides, Services and Solutions / HR Service Delivery: Guides and Services / HR Case Management: Guides and Services / Common ServiceNow HR Case Management Mistakes and How to Avoid Them

Common ServiceNow HR Case Management Mistakes and How to Avoid Them

This guide sets out common mistakes in HR case management rollouts in ServiceNow, each with its symptom, root cause and fix. It covers mixing cases with incidents, privacy and access rules, policy questions, SLA and escalation paths, training and assignment, and self-service knowledge.

Mistake 1: Mixing Case Management with Incident Management

Symptom: HR and finance staff are confused about whether to create a case or an incident for employee requests. Cases and incidents route differently and are tracked separately, leading to lost visibility and delays.

Root cause: The organization did not clearly define when to use Case Management versus Incident Management. Both modules exist in ServiceNow and can handle similar workflows, creating confusion.

Fix: Establish clear decision criteria. Use incidents for urgent issues that require immediate response: system outages, security breaches, or critical compliance violations. Use cases for employee requests that follow a process but are not time-critical: benefits enrollment, policy interpretations, or workplace accommodations.

Prevention: Document the distinction in your implementation plan and include it in training materials. When onboarding new HR staff, explicitly walk through examples of incidents versus cases and the routing rules for each. Reference this guidance during regular HR team meetings.

Mistake 2: Insufficient Privacy and Data Protection Measures

Symptom: Employees are concerned that HR data is visible to people who should not see it. Sensitive information about benefits, pay, performance, or health accommodations is accessible to peers or managers who do not need to know.

Root cause: Case-level permission rules were not configured, or were too loose. HR staff have broad access to all cases by default. The organization did not think through data sensitivity and access requirements during configuration.

Fix: Implement case-level security rules that limit visibility based on role and need-to-know. Employees should see only their own cases. HR processors should see cases they are assigned to. HR management should see cases for their department only, unless they have explicit oversight responsibility. Depending on your release and licensing, use field-level security to hide sensitive information from broader audience than case itself.

Prevention: During implementation planning, involve your legal and compliance teams to identify sensitive data categories and access requirements. Document security requirements and test them before go-live. Conduct quarterly audits of case permissions to confirm they remain appropriate as staff roles change.

Mistake 3: No Formal Process for Policy Interpretation

Symptom: When employees ask about policy (e.g., “Am I eligible for paternity leave?” or “How does the tuition reimbursement policy apply to my situation?”), HR staff provide conflicting answers. Employees open multiple cases seeking clarification and are frustrated by inconsistent guidance.

Root cause: The organization does not have a formal process for documenting policy interpretations or ensuring consistency across HR staff. Case responses are ad hoc and based on individual knowledge rather than documented guidance.

Fix: Create a knowledge base of common policy questions with authoritative answers. When HR staff encounter a new policy interpretation question in a case, they should follow a process to escalate to HR leadership for a binding interpretation, then document the answer in the knowledge base for future reference. This ensures all employees get consistent answers.

Prevention: Include knowledge base development in your implementation plan. Start with questions and scenarios that currently create confusion. Review case backlogs to identify the most frequent policy questions and document answers for those first.

Mistake 4: No SLA or Escalation Path for Urgent Cases

Symptom: An employee is waiting for approval to work from home due to a medical accommodation, but their case sits in the backlog for two weeks. Another employee is on unpaid leave waiting for a leave benefits determination and does not know when to expect an answer.

Root cause: The organization did not define SLAs for case types or assign ownership. Cases have no escalation path when they are delayed. HR staff do not prioritize urgent cases differently from routine requests.

Fix: Define SLAs for each case type. Urgent cases (medical accommodations, critical leave decisions, compliance-related requests) should have SLAs measured in hours or days. Routine cases (benefits enrollment, form requests) can have longer SLAs. Configure escalation rules so cases that breach SLA automatically escalate to HR management for action.

Prevention: Involve HR and management in defining SLAs during implementation planning. Set realistic targets that you can meet consistently. Review SLA performance monthly and investigate cases that are breaching. If you consistently miss SLAs, the targets are unrealistic or your team is understaffed.

Mistake 5: Inadequate Training and Case Assignment Logic

Symptom: Cases are not assigned to the right person. A benefits question routes to payroll, who re-routes it to HR, who re-routes it back to payroll. This chain delays resolution and frustrates both employees and staff.

Root cause: The organization did not define clear assignment rules or did not communicate them to the team. Case categories and routing rules are too broad or ambiguous. Staff do not understand their own responsibilities.

Fix: Define case categories that map cleanly to HR functional areas: benefits administration, leave management, compensation, policy interpretation, recruiting, and so on. Create routing rules that automatically assign cases to the right queue or person based on category. Test the routing logic with sample cases before go-live.

Prevention: Document all case categories and assignment rules in a reference guide. Include decision trees that help HR staff categorize cases correctly. Train all HR staff on the categories, assignment logic, and their own responsibilities. Run periodic reviews of unassigned cases to spot categories or scenarios that the routing rules are missing.

Mistake 6: Inadequate Knowledge Base and Employee Self-Service

Symptom: The HR team is overwhelmed with repetitive questions. Employees open cases asking “When is open enrollment?” or “How do I update my emergency contact?” that could be easily answered with self-service resources.

Root cause: The knowledge base is incomplete or not promoted to employees. The self-service portal is hard to find or does not surface relevant articles. HR staff do not direct employees to self-service resources.

Fix: Build a comprehensive HR knowledge base with articles covering benefits, leave, policy, payroll, and frequently asked questions. Integrate the knowledge base into the employee self-service portal. Configure the portal so employees see relevant articles before they open a case. Train HR staff to respond to cases by pointing to related articles and encouraging employees to self-serve in the future.

Prevention: Prioritize knowledge base development during the implementation plan. Start with the most frequent questions, then expand. Review case trends monthly to identify common questions that should have knowledge base articles. Measure knowledge base usage and satisfaction, and refine content based on what employees find helpful.

Four errors that surface after the first month of live cases

The early problems in an HR case program are often visible within days: a routing rule sends work to the wrong queue, or an approver never receives a request. The errors that cause more lasting damage tend to appear later, once the team is busy and the original design is out of memory. This section covers four of them. They are different from the access, routing and policy issues discussed elsewhere in this library, and they are most useful for the case queue lead and the HR systems owner who are reviewing a program that has been running for a few months.

Mistake: one case type stretched to cover everything

Teams often start with a single generic case type so that the first release is simple. Over time every new kind of request is added to it as a category, a custom field or a note. The result is a type with dozens of optional fields, most of which are blank on any given case, and a workflow that has to branch so many ways that nobody can read it. Reports then group together matters that differ in urgency, confidentiality and approval path.

Symptom: a case closes with a long list of empty fields and reviewers cannot tell which fields apply. Fix: split the generic type into specific types where the approval path, the visibility rules or the service level genuinely differ, and retire the categories that only exist to avoid creating a new type. Prevention: require a short business case before any new category is added to an existing type.

Mistake: closing a case before the outcome is recorded

Under pressure, staff close a case as soon as the employee has been spoken to, and the decision itself is recorded in an email or a meeting note. The case shows as resolved, but the record cannot answer what was decided, by whom or on what basis. This matters most in the cases where an employee later challenges the outcome.

Symptom: resolved cases with no outcome field completed and a comment that says only “discussed”. Fix: make the outcome and the decision-maker mandatory fields before the closure state can be selected, and check a sample of closed cases each month. Prevention: define what a closed case must contain as part of the case type design, not as a line in a training slide.

Mistake: letting metrics be defined after go-live

When the first reports are built after launch, the people building them often take whatever fields are easiest to query. The measures that come out tend to count activity rather than outcome: cases opened, cases closed, average touches. Those numbers look healthy while the queue is quietly accumulating stalled matters.

Symptom: a dashboard that shows high closure volume alongside a steady rise in reopened cases. Fix: agree the three or four measures that matter for each case type before the first live case, and check that each one can be produced from a field that staff are required to complete. Prevention: include the measure definitions in the same document as the case type definitions, reviewed by the same people.

Mistake: no retention rule for closed cases

Closed cases are often kept indefinitely because deleting them feels risky. That creates a different risk. Sensitive records remain visible to wide audiences, sometimes through reports and list views that were never meant to show them, and the organization holds more personal information than its own rules permit.

Symptom: old investigation records appearing in a general HR report or a search result. Fix: set a retention rule per case type with the legal and compliance team, and apply it through the platform rather than by hand. Prevention: review retention and report visibility together, since a retention rule is only as good as the views that expose the data.

Questions about spotting these errors early

How quickly should these problems show up?

The closure and outcome problem often shows in the first sample audit. The metrics problem appears when the first leadership report is questioned. Retention problems often stay hidden until someone searches the system for an old record. Schedule a check for each one rather than waiting for them to surface.

Is it worth fixing a generic case type that already has live cases?

Generally yes, but carefully. Migrate new cases to the specific types first, leave the existing cases where they are, and retire the generic type only once it is no longer receiving work. Changing the type of open cases in bulk can break their approval history.

Next step for a case review

Have the list of case types you run and a sample of closed cases ready. The HR case and knowledge design page covers how intake, privacy and ownership connect for each case.

Related guides: ServiceNow HR Case Management KPIs and Metrics That Matter and ServiceNow HR Case Management: Security and Access Design.

Frequently asked questions

How do we decide which HR requests should be cases versus incidents?

Use incidents for urgent issues requiring immediate response: critical compliance violations, security breaches affecting HR systems, or data loss events. Use cases for employee requests following a process: benefits enrollment, policy questions, leave requests, or accommodations. Incidents typically resolve in hours; cases may take days or weeks.

How do we protect sensitive employee information in cases?

Implement case-level permissions so employees see only their own cases and HR staff see only cases they own or are assigned to. Use field-level security to hide sensitive information like salary, performance ratings, or medical details from broader audiences. Conduct quarterly security audits to verify permissions are still appropriate.

What should our SLAs be for common HR case types?

Urgent cases (accommodations, leave decisions, policy interpretations affecting pay or benefits) should have short SLAs set by the HR lead. Routine cases (form requests, address updates, general inquiries) can have longer SLAs. Set realistic targets that your team can meet consistently, or staff will stop paying attention to SLAs.

Talk to Oblytech

Planning, running or fixing a ServiceNow programme? Tell us where you are and we will suggest a sensible next step.

Contact us