- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hi all,
I'm trying to understand the exact execution order between ACL processing and Security Data Filters.
From the ACL documentation:
- A Pre-query ACL check occurs before a database query is executed.
- The pre-query check only evaluates user roles and does not evaluate conditions or scripts.
Explore Access Control Lists • Australia Platform security • Docs | ServiceNow
From the Security Data Filter documentation:
- Security Data Filters are applied before a query is executed.
- Security Data Filters are applied after absolute ACLs (table-level ACLs) and after row ACLs.
Conditional ACLs filter data after a query is executed.
Security data filters • Australia Platform security • Docs | ServiceNow
This raises a question for me.
Are the following concepts referring to different stages of processing?
- Pre-query ACL check
- Absolute (table-level) ACLs
- Row ACLs
- Conditional ACLs
Security Data Filter
For both admin and non-admin users, what is the exact end-to-end execution order of Pre-query ACL checks, table-level (absolute) ACLs, row ACLs, conditional ACLs, Security Data Filters, and the database query itself?
Thanks in advance for any clarification or examples you can provide.
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago - last edited 3 weeks ago
Hi @IrisLe
The simplified mental model is:
Role gate → table gate → SDF (query rewrite) → DB query → per-row conditional ACL filtering
One nuance on the "row ACLs" placement in the SDF docs: the docs reference them in the context of which ACL types SDFs run after, meaning SDFs are evaluated knowing the row-level ACL definitions exist, but the actual per-row evaluation of conditional ACLs still happens post-query. The SDF doc language is about precedence/layering, not literal execution timing.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago - last edited 3 weeks ago
Hi @IrisLe
The simplified mental model is:
Role gate → table gate → SDF (query rewrite) → DB query → per-row conditional ACL filtering
One nuance on the "row ACLs" placement in the SDF docs: the docs reference them in the context of which ACL types SDFs run after, meaning SDFs are evaluated knowing the row-level ACL definitions exist, but the actual per-row evaluation of conditional ACLs still happens post-query. The SDF doc language is about precedence/layering, not literal execution timing.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hi @IrisLe
Refer KB: KB0541355 How Access Control List (ACL) evaluation works in ServiceNow
https://www.servicenow.com/community/grc-forum/order-of-execution-of-an-acl/m-p/1311960
Regards
Tanushree Maiti
ServiceNow Technical Architect
LinkedIn: https://www.linkedin.com/in/tanushreemaiti
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hi @IrisLe ,
I agree with @pratikbhatt's explanation. The confusion comes from the documentation using precedence and execution timing somewhat interchangeably.
A practical way to think about the execution order is:
Pre-query ACL role check – verifies whether the user has the required roles (no script or condition evaluation).
Table-level (absolute) ACLs – evaluated before the query proceeds.
Security Data Filters (SDFs) – rewrite or constrain the query before it is sent to the database.
Database query – retrieves only the records permitted by the rewritten query.
Row/conditional ACLs – evaluated against each returned record (including any scripts and conditions), filtering out records the user still cannot access.
So while the SDF documentation states that SDFs are applied after absolute and row ACLs, it's referring to the security precedence/layering rather than the literal runtime sequence. The actual per-record evaluation of conditional/row ACL scripts cannot occur until after records have been returned from the database.
That's why the simplified flow of:
Role gate → Table ACL → Security Data Filter → Database Query → Per-record Conditional ACL evaluation
is the best mental model to use.