Query Business Rules vs. ACL - comparison

Hi everyone,I recently had to explain to someone the difference between Query BR and ACLs and realized that this is an ongoing debate topic for many people. Opinions on which method of restricting acc

weixin_47584092

299人浏览 · 2025-08-29 10:53:43

weixin_47584092 · 2025-08-29 10:53:43 发布

Hi everyone,

I recently had to explain to someone the difference between Query BR and ACLs and realized that this is an ongoing debate topic for many people. Opinions on which method of restricting access is preferred are quite divided.

Below I would like to show a comparison of several areas and how both methods impact the specific area.

Area	Query BR	ACL	Comment
Access restriction	Row-level only (e.g. entire Incident record)	Global, table or field level	Use ACL if you need "conditional" access to some fields or if you want to set some fields read-only in a safe way.
User Experience	Will only show the records the User can see, with no message at the bottom about "some records removed due to security". E.g. if there are 500 Incidents but the User can only see 10, it will show one page with only 10 records.	Will show all pages with the restricted records being "invisible" and a message at the bottom "some records removed due to security". E.g. it will show 10 pages of records, but the user will only see 1 record on each page - the rest will be empty rows.	The ACL way of showing records can be annoying for users who sometimes have to click through a lot of empty pages to get to the records they want to see. It also makes bulk editing from list difficult. On the other hand, some prefer to show this to users as it makes them aware restrictions are in place.
Performance	Query BR are only evaluated once per each table query. They just return the resulting records from DB to the application.	ACLs have to be evaluated for every record/field individually.	Query BR can provide a performance boost in some cases, compared to ACL. Note: for tables with a lot of logic/scripts (like Task table) they will impact ALL calculations, which can be disaterous to the performance! See comments below the article.
Debugging	You cannot debug Query BR using the "Debug Security" module.	ACLs can be easily debugged with "debug security"	Query BR will be shown in the "Debug Business Rules" module, but you can only see that a particular BR has run, no info on whether it actually restricted any records.
Impact on Scripts	Query BR will impact all your scripts running on the table where the BR is applied. E.g. if you have a script doing a GlideRecord on Incident table, it will be affected by Query BR according to the restrictions put in it.	ACLs are not impacting the scripts. Exceptions being: using GlideRecordSecure or adding "canRead/canWrite" etc. to your GlideRecord in scripts.	Query BR can make script debugging really hard sometimes.
Scoped Applications	You cannot create Query BR on tables from a different scope within a scoped app.	You cannot add roles to ACLs from a different scope. You cannot use script evaluation in ACL wihch is for a table in a different scope. You cannot create wildcard (*) rules for tables in a different scope.
User Impersonation	In some cases, it was impossible to properly test or debug Query BR by impersonating a user. We actually had to log in as that user to see the real effect*	No known issues related to impersonation.	*I have not been able to reproduce this now, but our testers reported this issue on several occasions. Keep this in mind just in case.
Update Sets	Query BR can impact the proper inserting or updating of records via Update Sets - e.g. if on target instance, you don't have access to a specific record due to Query BR and try to update it via an Update Set, it won't happen.	No adverse impact on Update Sets.	Under normal circumstances, you will probably not be affected by this behaviour. Things get interesting when you start restricting configuration files.

Edit (based on fredjean's comment below): You should avoid using ^NQ (master OR) operators in Query BR queries. This can cause issues mentioned in the below article: Using operator (^NQ) in encoded queries causes incorrect reference links in the list view - Known Error - Now Support Portal

hopefully this will help someone make an informed decision.

I use both of these methods depending on the specific case. For sure, if you decide to go with Query Business Rules, it helps to have them properly documented somewhere, as it is a much less natural and obious place to look for any access restrictions.

2048 AI社区

有“AI”的1024 = 2048，欢迎大家加入2048 AI社区

更多推荐

M-VLM【1】：Multi-Resolution Pathology-Language Pre-training Model with Text-Guided Visual Representati

2048 AI社区

网络安全行业真的凉了吗？这条路还能走吗？

2048 AI社区

vue3+elementUI-plus el-tree二次封装

{id: 9, label: '三级 1-1-1', parentId:4,hasRight:true},"parentName": "第6组织","parentName": "第6组织","parentName": "第6组织","rootName": "第6组织","rootName": "第6组织","rootName": "第6组织","rootName": "第2组织","leader"