How to querying records on HR Cases under a CoE if the user is not part of the security policy?

[jpcb0108]

Hi All,

We have a record producer that creates specific HR Cases under a specific HR Service. The record producer has a script that calls a subflow queries the HR Case table to find out if another case with the same HR Service is open for the same subject person selected and they will be stopped from submitting a duplicate.

We did it this way so that we can set the subflow to run with the sn_hr_core.basic role so that it can query the HR Case table and return if there is already a case that has the same subject person and HR Service or not.

However, we are currently in the process of adding COE Security policies to this HR Service and due to this, unless the user who opens the first ticket is the same as the one who is trying to submit a duplicate, the subflow is not able to query records that are opened by others even though it has the same HR Service and Subject Person as the duplicate that will be submitted.

How should we go about making the check of whether there is already a case opened for the specific subject person and HR Service once the COE Security policies are in place? We won't be able to create a group and add it to the COE Security policy as well and we would like to keep it so that the people can only see the cases they raised themselves.

Thanks.

[Kieran Anson]

How are you querying the records? GlideRecord won't consider the security rules, but GlideRecordSecure will. Additional, breaking functionality into further sub flows can allow you to change the context from user to system, if you need to elevate for a specific use case

[jpcb0108]

Hi Kieran,

Currently, our subflow is using the Look Up Records action and we just have it output some boolean to tell whether it is true or false that a duplicate has been found. We are using the Run with roles to get through the ACL but this is without COE Security Policies in place yet.

With regards to using AJAX and GlideRecord, the users submitting do not necessarily have the HR roles so, correct me if I am wrong, but even if we can bypass the Security rules, the ACLs would be the one blocking us instead since they don't have the role to read all the records. And aside from the checking of whether there is already a case similar to the one they are trying to submit, we want to limit the users to seeing only cases they have submitted.

[Kieran Anson]

Hi,

Might be easier if I explain my understanding of the process you have.

You have a record producer and a client script that calls your subflow? The subflow is being called by the GlideFlow.startSubflow API available client side? This runs in the user context, with the addition of the HR role to bypass ACLs restrictions currently in place.

My suggestion is to break down your subflow into to parts. Your subflow can call a further subflow that is set to run as a system. Within this nested subflow, you can perform your HR case lookup as 'system' user which will bypass ACLs checks.

You need to be careful with this, particularly not to return data as you're bypassing authorisation checks

Process:

1. Client script triggered (onChange, onSubmit etc)
2. Client script calls GlideFlow.startSubflow('global.check_can_read_hr_case')
3. check_can_read_hr_case runs as user, with addition of HR basic role
4. check_can_read_hr_case calls subflow 'check_can_read_protected_cases'
5. check_can_read_protected_cases runs as system
6. check_can_read_protected_cases performs look up action as system user
7. check_can_read_protected_cases returns data