ACL or Query Business Rules?

Every now and then I find myself in a debate with a colleague about whether to use an ACL or a Query Business Rule for restricting data access.

Personally, I think the use of Query Business Rules should be minimised. Here is why.

The Core Concern

ACLs are called ACLs for a reason: they exist to enforce security. In most organisations, only a security admin can modify ACLs. Query Business Rules, on the other hand, can be modified by anyone with the personalize_rules role — which is a much wider audience, and those rules can be integral to your data security model.

I am not saying never use Query Business Rules. I am saying they should be used deliberately and sparingly.

When Not to Use a Query Business Rule

Avoid Query Business Rules in the following scenarios:

• The query will run on a large table. Query BRs execute for every query on a table, adding overhead. On large tables (hundreds of thousands of records), this adds up.
• The query contains many OR clauses or LIKE operators. These are expensive query patterns that can cause performance issues at scale.
• You care about instance performance. If performance is a priority, ACLs are evaluated more efficiently by the platform than Query BRs.

The Better Mental Model

Think of ACLs as your first line of defence — consistent, auditable, controlled. Query Business Rules can still be useful for adjusting what a user sees in a list view based on their context, but they should never be the primary mechanism protecting sensitive data.

When in doubt, ask: if this rule were accidentally modified or deleted, would sensitive data be exposed? If the answer is yes, use an ACL.