Are BR scripts honoring ACLs now?

[ariannegrocales]

Hi, I have an issue in a BR where it is apparently failing to execute due to ACL restrictions.

Use case: Update the parent INC's watchlist if the child ITASK gets an Assigned To (an interim solution for a different use case). So, fulfillers will be assigning the ITASK to themselves, and they will then have access to the parent ticket as watch list.

Raised the issue in Support and their only reply is that the user is failing in the incident.watch_list ACL, which is why script is not executing as expected. However, looking at community/support articles mention otherwise:

Solved: Can a business rule, triggered by an end-user, upd... - ServiceNow Community

Relationship between Business Rules and Access Control Rules (ACLs) - Support and Troubleshooting (s...

Based on both articles, GlideRecordSecure is the only way to honor ACLs on a script, however our script is only using GlideRecord. Am I missing something or are ACLs expected to be honored in BR executions now?

[luffy3478]

run the script in background script to see if the script is actually working. 

remove the conditions on BR to see if the issue with them and then check if roles field on 

[Bert_c1]

Here's a good resource:

https://developer.servicenow.com/blog.do?p=/post/gliderecord-vs-gliderecordsecure/

May help.

[ariannegrocales · Accepted solution]

Just for an update, this issue has been resolved.

Issue was due to the BR script having an update(), which subsequently also triggered a query BR we have in the incident table. And due to the rules of the query BR, the update was blocked (since the query BR still assumes the persona of the user triggering the BR, which in this case is also blocked from actually updating the parent record).

Workaround we did was to reuse the logic into a Flow instead, since Flows can run as System User (bypassing the query BR's blocking).