Best Practices for Designing a Preliminary HR Case Triage Process

ghzelmed · 3 weeks 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!

Max Dore · 2 weeks ago

Hi @ghzelmed , this is my personal recommendation, not a ServiceNow vetted or endorsed standing:

I think I'd recommend keeping the preliminary assessment classification separate from the Ethics/allegation taxonomy, storing Type and Subtype on the Employee Relations case, and starting with two dependent choice fields rather than a custom classification table.

Extending the existing allegations taxonomy makes sense when the new values genuinely describe allegations. However, your classification also includes employment procedures and potential outcomes, such as contract non-renewal, probation extension, and restructuring. A separate classiffication would preserve the meaning of the existing Ethics taxonomy while allowing allegations to be recorded where misconduct is involved.

Before changing Principal Reason you should verify if its reference table, reference qualifier, and existing dependencies. Confirm whether it references a taxonomy definition or an allegation record associated with a case.

For intake i think use Record Producer variables mapped to dedicated case fields. The variables provide the user experience, while the case fields provide the authoritative classification for agent handling, workflow, and reporting. This also supports cases created directly by agents rather than through the Record Producer.

I suggest using Assessment Case Type and Assessment Subtype, with Subtype dependent on Case Type. Consider adding an Assessment Decision field to record whether the situation should be resolved informally or proceed to a formal procedure. Keeping that decision separate prevents classification from being confused with the assessment outcome. Configure and test the dependency separately on the case form and the Record Producer.

Persisted case fields are my preferred reporting foundation. They support consistent analysis of case volumes, subtype trends, informal resolutions, and formal escalations. Existing ER reportss may need configuration to include these fields.

For your current hiererchy, dependent choices are the simpler starting point. I'd say introduce custom classification tables only if the taxonomy needs additional governed information, like ownership, applicability rules, or relationships to formal procedures.

For the process itself, maybe configure a Preliminary ER Assessment HR service within the existing ER COE, use a case template and, where needed, a Record Producer. The process would capture and classify the situation, record an assessment decision, and then either resolve it informally or initiate the appropriate formal procedure.

Continue the same case when assessment and formal handling belong to one controlled process. Consider a linked child case when formal handling needs a distinct service or operational boundary. Validate how evidence, allegations, interviews, and access restrictions are handled rather than assuming they transfer automatically.

Review delivered services such as PIP and PIP Assessment before building performance-specific fulfillment, but don't assume they cover the broader preliminary assessment requirement.

Apply confidentiality restrictions from initial intake, also test every case creation channels, and regression-test field mappings, dependencies, fulfillment, and visibility after upgrades.

Overall, separate case classification fields and HR servicebased fulfillment offer a practical balance between reporting, maintainability, and limited customization. I would say to only add custom classification tables only when their governance benefits justify the additional maintenance.

sanjaygupta · Thursday

I'd recommend keeping the preliminary assessment separate from the existing Ethics/Allegation taxonomy. A ServiceNow employee also shared this approach in the replies, recommending dedicated case fields rather than extending the existing Allegation table.

Create two custom fields on the Employee Relations case for Assessment Case Type and Assessment Subtype.
Configure Subtype as a dependent choice field based on Case Type.
Create matching Record Producer variables and map them to the case fields.
Add an Assessment Decision field to capture whether the case should be resolved informally or escalated to a formal process.
Configure a Preliminary ER Assessment HR service under the existing ER COE.
Use a case template and Record Producer to manage intake and fulfillment.

For reporting, storing values directly on the HR case is preferable to keeping them only as Record Producer variables.

One additional recommendation from the reply is to continue with the same case when the assessment and formal handling belong to one process. Use a linked child case when they require separate access controls or operational handling.

Avoid extending the Allegation table unless the new classification genuinely represents allegations. Also, apply confidentiality restrictions from the initial intake, given the sensitive nature of Employee Relations cases.

References:

Hope you find this helpful.