Security Data Filters in ServiceNow

[Vaishnavi Lathk]

Overview

Security Data Filters (SDFs) in ServiceNow restrict access to records based on user roles or security attribute assertions. These filters are applied before a query is executed, ensuring only authorized users can access sensitive data—whether through the platform UI, API, reports, or exports.

---

Key Features

• In-query Enforcement: Filters apply directly to SQL queries, improving data protection at the database level.

• AND Logic: Multiple filters on the same table are combined using logical AND.

• Independent of ACLs: SDFs are not checked via canRead() and function separately from Access Control Rules.

• Scoped by Table: Security filters apply based on table scope, not the app scope hierarchy (ScopeMaster or sys_scope rules).

---

Application & Enforcement

• Security filters apply after table-level and row-level ACLs.

• By default, they are enforced on:

  • GlideRecordSecure

  • GlideRecordSandbox

  • GlideAggregateSandbox

To use filters with standard GlideRecord, enable them explicitly with:

gr.enableSecurityFeature("data_filter");

⚠️ Always explicitly enable SDFs for user-facing queries that do not use GlideRecordSecure.

---

Use Cases

Security Data Filters are ideal for:

• Preventing sensitive data exposure via API or export.

• Removing "rows hidden by security" messages.

• Restricting data in reports, dashboards, or mobile views.

⚠️ Use caution with:

• Large numbers of filter conditions

• Filters on unindexed fields

• Using them as visibility controls (consider ACLs instead)

---

Filter Behavior

Multiple filters are combined like this:

SELECT * FROM task WHERE state != closed AND active = true AND priority = 1 AND state = open

Important points:

• Filters on child tables do not propagate to parent tables.

• To enforce restrictions on both, create filters on each table.

---

How to Create a Security Data Filter

Before You Begin

Ensure you have the admin or security_admin role.

Steps

1. Navigate to All > System Security > Security Data Filters.

2. Click New.

3. Fill out the form:

Field	Description
Table	The table to which this filter applies
Description	Summary of the rule
Active	Activate when ready to apply
Show in UI	Displays a UI message when triggered
Application	Scope for this filter
Mode	Condition mode (If/Unless a security attribute is met)
Filter	Record-level filter conditions
Security Attributes	Criteria to control filter applicability

4. Click Save.

📝 Keep new filters inactive while testing to avoid unexpected access restrictions.

---

Default Locations Where Filters Apply

Category	Applies To
List & Form Views	UI16, Workspaces, Service Catalog, Portal, Mobile
Reporting	Legacy & Modern Dashboards
Data Export	XML, CSV, Excel, JSON, PDF
Glide APIs	GlideRecordSecure, Sandbox types
APIs	REST Table, Stats, GraphQL equivalents

---

Performance Considerations

Poorly optimized filters can degrade system performance. Key risk factors:

• Number of filters

• Query complexity

• Use of unindexed fields or operators (contains, LIKE)

Use the Security Data Filter Performance Analysis Tool to evaluate performance impact.

---

Using the Performance Analysis Tool

1. Enable diagnostic mode:

   • Set system property:
     glide.security.data_filter.diagnostic_enabled = true

2. Go to System Security > Security Data Filters.

3. Open the filter to analyze.

4. Click Analyze Performance.

Form Fields

Field	Description
Data Filter	The filter being analyzed
Related Active Filters	Count of all active filters
Table	The affected table
Encoded Query	Sample query for analysis
Query Runs	How many times to run the test (10–100)

Results

The Performance Summary shows execution time comparisons with and without the filter, using these indicators:

Indicator	Impact
Low	0% change – no impact
Medium	Up to 100% increase – moderate
Critical	Over 100% increase – significant slowdown

---

Best Practices

✅ Use filters to prevent unauthorized access, not to handle UI visibility
✅ Avoid filters on unindexed fields or using contains
✅ Use the Performance Analysis Tool regularly
✅ Always test in a non-production environment

---

Conclusion

Security Data Filters are a powerful, low-level mechanism to enforce data access controls across APIs, exports, and queries. When implemented thoughtfully, they can significantly enhance the data protection posture of your ServiceNow instance.

For more help, contact your ServiceNow Security Architect or consult the ServiceNow Documentation.

[DineshS]

To create a security data filter, Sec Admin is required. Please correct me if I am wrong

[Vaishnavi Lathk]

Yes

[Di Zhang]

What's the difference between security data filter and before query?

[Mwatkins]

@Di Zhang There are some differences between a Security Data Filter (SDF) and a Before Query Business Rule (BQBR), but they are very similar.

Similarities

1. Both SDFs and BQBRs apply directly to SQL queries, improving data protection at the database level. This carries with it many performance and logical implications noted in the article above as well as in the link I've supplied below.
2. BothSDFs and BQBRs do not propagate to the parent table. So, for example, an SDF defined against the Incident table will not be applied to Incident records if those Incident records are viewed by opening a list of Task records. In other words, you can bypass an SDF on the Incident table by opening a list on the Task table. For example, going to the URL /task_list.do?sysparm_query=sys_class_name=incident will show Incident records that would have otherwise been blocked by an SDF if accessed via the URL /incident_list.do.
3. Both apply to GlideRecordSecure and the other explicitly secure APIs by default

Differences

1. SDFs do not apply to GlideRecord by default, but BQBRs do apply to GlideRecord by default. This makes SDF better suited for security applications since it is usually undesirable to have security rules applied to contexts other than displaying data to a user.
2. SDFs were designed with the concept of security in mind, but BQBRs were not. SDFs are an official part of the ServiceNow Security architecture and, as such, undergo much more Quality Assurance testing to make sure they are suited for purpose.
3. SDFs will be added to both sides of a New Query condition (^NQ), but BQBRs will not. This is an often overlooked limitation of BQBRs. If someone queries the incident table with the filter active=1^NQstateIN3,7 and then adds short_descriptionLIKEburger with a BQBR the resulting filter will be active=1^NQstateIN3,7^short_descriptionLIKEburger. However, if the same condition is added with a SDF the resulting condition would be active=1^short_descriptionLIKEburger^NQstateIN3,7^short_descriptionLIKEburger
4. Multiple SDFs will be constructed using AND condition. BQBRs can add multiple conditions using OR conditions.

There are probably some other differences that haven't occurred to me yet, but these are the first ones that pop in my head.

With these differences and similarities in mind, many of the concepts discussed in the following article will be helpful when designing Security Data Filters.

https://www.servicenow.com/community/developer-articles/performance-best-practice-for-before-query-b...

Please ✅ Correct if this solves your issue and/or 👍 if Helpful

"Simplicity does not precede complexity, but follows it" - Alan Perlis