HRSD- Employee Relations COE- Investigators outside HR?

[robertlylem]

Hi all- wondering whether anyone had come across a good solution for instances where Employee Relations investigations are managed by an "agent" based not in HR, but in the line of business in which the complainant is based?  The typical set up of a resolver/assignment group (and a process for assigning agents to it) doesn't really work as typically a single "business" investigator should only see "their" investigations, which kind of implies a 1:1 relationship with user and resolver group. 

I can think of plenty of custom solutions for the issue but wondered if anyone had any tips based on some imaginative config I am missing, or maybe a feature I don't know about?

Thanks!

[musislam]

Hi robertlylem,

We've run into the same thing. As far as I know there's no OOB setting that limits an investigator to only their own ER cases, but two options get you close without creating a group per person:

1. Add the investigator as a Collaborator on the ER case. Collaborators get past the COE security policies, the same as opened for, opened by and watch list. One catch is that the collaborator lookup only lists HR agents OOB, so you may need to open that up.

2. If they only do the investigation work, assign them an HR task instead. They can work it from Employee Center with the normal employee role and never see the full case.

Before I go further, a few questions:

1. Do these investigators have HR fulfiller roles and licences, or are they regular employees?

2. Do they need the whole ER case (notes, parties, attachments) or just their part of the investigation?

3. Is the investigator picked per case by the ER case manager, or is it fixed by the complainant's business unit?

Also, which release are you on?

If that works for you, mind marking it as the recommended solution? Helps me support these better for the community.

Macki | Deloitte AU | Engineer Lead

[sachinvic]

@robertlylem 

Hi Robert,

You can absolutely achieve this without building a heavy, custom 1:1 user-to-group security model. The cleanest path forward is to layer ServiceNow’s native routing engine with a server-side query filter.

Here is the exact blueprint to configure this out-of-the-box (OOTB) and handle the strict 1:1 data isolation:

1. Open the Gateway with COE Security Configuration

First, check the native ER Case Restriction / COE Security Configuration. Employee Relations cases can be restricted to specific assignment groups, and users requiring access can be granted the scoped ER investigator role (sn_hr_er.investigator). This allows your line-of-business (LOB) agents to interact with the Employee Relations COE [sn_hr_er_case] securely without gaining visibility into global HR cases.

2. Auto-Route Cases using Assignment & Matching Rules

Instead of manual triaging, leverage HR Assignment Rules alongside Matching Rules to automatically route cases to the correct investigator based on the complainant's location, business unit, or required skills.

• Use the Assignment Rule to land the incoming case into your broad LOB Investigations assignment group.
• Use a Matching Rule (e.g., Agents by skills and country) to dynamically assign the case to the specific investigator in that group who holds the matching LOB skill and has the lowest workload.

3. Enforce the 1:1 Constraint via a "Before Query" Business Rule

By default, anyone in an assignment group can see all cases assigned to that group. To enforce your strict requirement where investigators can only see their own investigations, you need a record-level security layer.

Standard read ACLs will result in annoying "Number of rows removed by security constraints" messages on lists. The best-practice solution is a Before Query Business Rule on the ER Case [sn_hr_er_case] table. This alters the database query before it loads, seamlessly hiding unauthorized records.

FYR: 

https://www.servicenow.com/docs/r/employee-service-management/hr-service-delivery/hr-er-case-restric...