Performance of Access Control (ACL) - condition builder vs. script - what's faster?

peter_repan
Tera Guru

Hi all,

I have a question regarding the performance of ACLs. 

Let's imagine a case we have table with 20 fields and we need ACL with different conditions for each field.

We have option either to specify the conditions using "Condition" builder or use "Script" field and write the conditions in the script (f.e. using some Script Includes).

I'm interested what's faster for execution. And why? 🙂

Any ideas?

 

2 REPLIES 2

Goran WitchDoc
ServiceNow Employee
ServiceNow Employee

*EDIT* abit of misread the question, but I'll keep my other perspection down below. I would say condition builder if you don't start to dotwalk to much in there. Simply since it's built by servicenow and hopefully having the thought of performance in mind. Script it pretty much up to us to make sure it's top performing.

 

My first thought would be script. And that is of future adminstration. I will say that you probably will build it faster with condition builder, but if you later on would like to change etc. I would say a nice built script can probably handle this easier. Hard to say thou before know how complex the conditions are and so on.

//Göran
Feel free to connect with me:
LinkedIn & Twitter
Subscribe to my YouTube Channel
Buy The Witch Doctor's Guide To ServiceNow 

Thank you Goran for your message. 

I'm thinking to create a script include like "MyAccessUtils" with .canWrite(field_name) function and then I will put into each field ACL script like "answer = new MyAccessUtils(current).canWrite('<field_name>')" and put all the logic into one place - into Script Include. Therefore from maintenance point of view it's much easier to open single Script Include and update all rules from one place than edit each condition separately in Condition builder.

However, I'm unsure if such execution will not be too slow in comparison of the "Condition" builder field. That's reason why I'm asking. 

What kind of conditions I want to check: state of the task, if the current member is from assignment group or manager, some other task field values, etc. In general nothing what should be calculated, just check some existing field values.