Best Practices for Designing a Preliminary HR Case Triage Process

ghzelmed
Tera Contributor

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

  1. Classification model: Would you recommend extending the existing Allegation table or keeping this classification separate, given that the table already supports the Ethics taxonomy?

  2. 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?

  3. 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?

  4. 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!

0 REPLIES 0