Best Practices for Designing a Preliminary HR Case Triage Process
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
23m ago
Hi everyone,
I'm looking for recommendations on the best way to design a preliminary case assessment process in ServiceNow HR Service Delivery, specifically within Employee Relations.
Business context
The objective is to introduce an initial assessment process for sensitive employee-related situations before deciding whether a formal case management procedure is required.
The initial case would be used to assess the situation and determine whether it can be handled informally or needs to be escalated to a formal process. If an informal resolution is not appropriate, the case would then proceed through the relevant formal procedure.
Classification requirements
The form needs two fields:
Case Type: identifies the main category of the case.
Subtype: a dependent dropdown whose available options are determined by the selected Case Type.
The classification would follow this structure:
1. Employee Performance
Performance or conduct-related concern
Formal performance warning
Performance support plan
Probation period extension
Promotion confirmation unsuccessful
Performance-related disagreement or mediation
2. Employment Separation
Non-renewal of a fixed-term contract
Non-renewal of a senior appointment
Probation completion not approved
Termination by mutual agreement
Performance-related termination
Termination following disciplinary action
Role elimination due to organisational restructuring
Role elimination due to budget constraints or changing business needs
Position responsibilities redefined
Refusal to accept reassignment
Refusal to relocate to another duty station
Unable to return to work following an extended period of inactivity
3. Workplace Conduct and Relations
Workplace harassment
Retaliation or reprisal
These fields will be used to determine the appropriate workflow and support case classification and reporting.
Implementation options
The existing Employee Relations configuration includes a Principal Reason field that references the out-of-the-box Allegation table, which is currently used to support the Ethics taxonomy.
I'm considering three possible approaches:
Option 1 – Use Record Producer variables
Create Type and Subtype as dependent select-box variables on the HR Service Record Producer. These variables would be used to determine the workflow but would not be mapped to dedicated fields on the Employee Relations Case table.
Option 2 – Reuse the existing Allegation table
Add new records to the existing Allegation table to accommodate the classification required for the preliminary assessment process, and use the existing Principal Reason field to store the selected value.
However, since this table is already associated with the Ethics taxonomy, I'm not sure whether extending it for a different business purpose would be considered good practice.
Option 3 – Introduce a dedicated custom classification model
Create a custom table to manage the Type/Subtype relationship and add corresponding custom fields to the Employee Relations Case table.
This would provide a separate data model for the preliminary assessment process, but it would also introduce additional configuration and maintenance.
Questions for the community
Classification model: Would you recommend extending the existing Allegation table or keeping this classification separate, given that the table already supports the Ethics taxonomy?
Variables vs. Case fields: From a ServiceNow best-practice perspective, should Type and Subtype remain Record Producer variables, or should they be mapped to dedicated custom fields on the Employee Relations Case table?
Reporting: Since storing the values in Case fields would make reporting and data analysis easier, would you consider adding custom fields the preferred approach, or are there recommended alternatives?
Out-of-the-box capabilities: Are there any existing Employee Relations features or recommended design patterns that could support this requirement without unnecessary customization?
I'd appreciate any insights or lessons learned from similar implementations, particularly regarding maintainability, data model design, and alignment with ServiceNow best practices.
Thanks in advance for your help!
