HR Cases visibility
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎04-17-2024 02:11 AM
Hello everyone!
I am currently seeking for best practices around the visibility of HR Cases on the backend.
There is already an OOTB business rule "Restrict query" that comes together with "Human Resources: scoped app core" plugin and from my understanding, controls the visibility of the cases for non-HR Agents (users without the sn_hr_core.basic role).
Which is the best practice to restrict the cases on the backend for HR Agents?
In my opinion , creating a second "Before Query" business rule but only for users with sn_hr_core.basic role will be useful to have a standard query always, for example:
- All HR Agents will be able to see the HR Cases only for the country they belong OR
- All HR Agents will be able to see the HR Cases that are assigned to one of the groups they belong
Together with that Business rule, we can also have COE Security policies for any specific requirement around an HR Service. For example:
- For " Ask a generic question" cases , only HR Recruitment group should see the cases (Business rule active + COE Security policy)
What do you think ? Is the above approach following best practices ?

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎04-17-2024 06:19 AM
@GeoVic Gkou The COE Security policies are the best approach. These are the no-code configurations that do not impact the upgrade path, and in my opinion, are much easier to see what users can access in regards to authoring ACLs. There are use cases that expand out of the scope of COE Security configs (i.e., field-level ACLs) but where you can use COE Security policies, this is the recommended approach where the requirement is to restrict cases based on group membership. There have been some great enhancements to this feature since it was introduced, so I would explore the COE Security policies first.
If my answer has helped with your question, please mark my answer as an accepted solution and give a thumbs up.
Regards,
Mike
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎04-17-2024 06:27 AM - edited ‎04-17-2024 06:28 AM
@michaelj_sherid Thank you! Are they considered a good combination with a before query business rule right?
Because i would like to follow the below approach:
One "Before query business rule" that will have the standard conditions for the normal users (opened for, opened by , watchlist can see those cases) plus one initial condition for the users with HR Basic role:
........ etc.
If (user.hasRole("sn_hr_core.basic") {
or.addOrCondition("u_country", user.country);
}
Then for any specific requirement around an HR Service i was going to configure security policies.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎04-17-2024 06:50 AM
@GeoVic Gkou I am not sure if this is needed because the condition on the Restrict Query BR already has a condition that is looking for the case reader role. At a high level I am not certain the BR is needed in addition, but this may be my understanding of the use case.
Regards,
Mike
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎04-17-2024 06:56 AM
@michaelj_sherid Seems like the OOTB Restrict Query BR will not run for users with "sn_hr_core.basic" role:
OOTB Condition
gs.getUser().getName() != 'system' && (!new hr_Utils().checkUserHasRole(hr.ROLE_HR_CASE_READER))
This is the reason i thought removing entirely this condition and "adding" later in the script the above lines that will refer to HR Agents:
If (user.hasRole("sn_hr_core.basic") {
or.addOrCondition("u_country", user.country);
}