A common requirement I've either been asked to implement, or review over the years, is an implementation of "HR for HR" case visibility restrictions. In other words, if a case is raised and is relevant to a person in HR - the subject of the case, just like a standard employee, should not see it.
This is normal, and in fact catered for in the context of employee relations cases in ServiceNow but not in the other non ER HR case tables.
My first recommendation is always to challenge the requirement robustly. When it comes to case security, build as fewer restrictions into what different group of Agents can see as possible. Do not fall into the trap of confusing HR agents not needing to work on or see cases, as a reason to lock them away completely. You will increase time required to build, test and maintain your solution and you will suffer in terms of operational efficiency and agility.
If you feel that you still need HR for HR outside the context of Employee relations then it is important to create this customization in a way that will have minimal impact on upgrades.
A common approach is to modify the Access Control Lists, or the scripted checks in the HR solutions Script Includes (e.g. hr_Case). Avoid both of these techniques unless absolutely necessary.
One of the things that you can do instead now is to create a single new "Deny Unless" ACL per case table, which kicks in if the user is the subject, is not also the opened for (because often you're both), and the case option for allowing subject person to see a case is not set.
That will stop the agent getting into a record, but they will likely know, or at least suspect that there is a case where they are the subject. Why? Because when they look at a list of cases they will see a message informing them that records have been removed due to security constraints.
We can avoid this scenario, and indeed avoid creating the ACLs too by creating a before query business rule on the HR Case table, which mirrors the one already there for normal employees without the case reader role. I.e. we create one specifically for users with the case reader role.
(note: This code is only an example. It's not destruction tested beyond the basic examples I show later)
With that in place, a quick test. I create three cases; one where the opened for user is one HR Agent (Drake) and the subject is another HR agent (Cassie). Another general inquiry where cassie is both the subject and the opened for. Lastly, one where Drake is the opened for, cassie the subject, but where the HR service is marked for subject person visibility- a new HR service in the same table, called "New Open General Inquiry"
If we have the solution right, when looking at a list of cases created today, Drake should see three but Cassie only two.
As Drake…
As Cassie…
Et voila. A single business rule, and we have our HR for HR restrictions at case record level in place.
