--- sourceDocument: Brazil Platform security sourceDocumentLink: https://www.servicenow.com/docs/r/platform-security Release : - brazil ft:locale : - en-US ft:publication_title : - Brazil Platform security ft:clusterId : - psec bundleId : - psec workflow : - Platform --- # Security data filters # Security data filters {#ariaid-title1} Release version: Brazil Updated September 10, 2026 ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 2 minutes to read Summarize ![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete. ## Summary of Security data filters Security data filters in ServiceNow Brazil release enable you to restrict access to records based on user roles or other security attributes. These filters are appliedbeforequeries are executed, ensuring sensitive data never leaves the database, which enhances data security compared to conditional ACLs that filter data after query execution. This pre-query filtering ensures only authorized users see the data they are permitted to access. Show full answer Show less ## Key Features * Security data filters are applied directly in the database query, combining multiple filter conditions using logical AND operations. * Filters operate on the target table and do not adhere to ScopeMaster or sysscope scope rules but instead follow data filter scoping based on the table. * They are applied after absolute (table-level) and row ACLs and are enforced by default on GlideRecordSecure, GlideRecordSandbox, and GlideAggregateSandbox queries. * New GlideRecord APIs `enableSecurityFeature` and `disableSecurityFeature` allow explicit enabling or disabling of security data filters in server-side scripts and Java. * To maintain consistent security, it is recommended to pair security data filters with Deny-Unless ACLs. ## When to Use * To prevent sensitive data from leaving the database. * To suppress the "rows hidden by security" message commonly seen in interfaces. * To avoid data leakage through reports. ## When Not to Use * Do not use security data filters as a replacement for visibility controls or ACLs. * Avoid using them when there are a large number of filter conditions or when filtering on unindexed columns because this could impact performance. ## Behavior and Application Details * Multiple security data filters combine using logical AND, further restricting query results by adding conditions to the initial query. * Data filters applied on child tables do not implicitly apply to parent tables; therefore, filters should be added to both parent and child tables to restrict access properly. * Security data filters affect system behavior globally and must be used carefully to avoid unintended access issues. ## Practical Considerations for ServiceNow Customers As a ServiceNow customer, using security data filters helps you enforce robust data security at the database query level, preventing unauthorized data exposure and improving compliance. You should explicitly enable these filters on user-facing queries that do not use GlideRecordSecure and pair them with appropriate ACLs to maintain consistent access controls. Be mindful of filter complexity and performance implications when designing security data filters to ensure efficient and secure data access. Security data filters restrict access to records based on role, or security-attribute related assertions. ## Exploring security data filters {#security-data-filters__section_bbd_bc1_b2c} Security data filters enable access restriction to records based on a users' role, or other security attribute related assertions. Security data filters ensure only authorized users can view records regardless of how data is accessed. Security data filters are applied before a query is executed so restricted data never leaves the database. In contrast [conditional ACLs](https://www.servicenow.com/docs/n~MLU9OizdlQo7fDhOrk0Q "Access control lists (ACLs) restrict access to data by requiring users to pass a set of requirements before they can interact with it.") filter data after a query is executed possibly leaking data. Note: Pair security data filters with [Deny-Unless ACL](https://www.servicenow.com/docs/E_KuI3OCo6mLVpl~45DyaA "Learn details about Deny-Unless ACLs.") to ensure consistent security ## Features of security data filters {#security-data-filters__section_umz_dc1_b2c} The key features of security data filters are: * Security data filters are applied in-query. * Security data filter conditions AND to the query on the target table and with each other. * Security data filters are not checked by `canRead`. See [When to use security data filters](https://www.servicenow.com/docs/ZydmbXmUlU1J_gms96u~9g#security-data-filters__section_dqx_2c1_b2c) for more details * Data filter scoping rules are based on the scope of the table, data filters do not follow ScopeMaster or sys_scope scope rules {#security-data-filters__ul_n2r_sh1_b2c} ## Security data filter application and enforcement {#security-data-filters__section_wrk_ph1_b2c} Generally security data filters are applied after absolute ACLs (also called table-level ACLs), and after row ACLs. Security data filters are applied by default, and impact system behavior if not used carefully. See [Default security filters](https://www.servicenow.com/docs/L2vYF6tBR2ZRWwIJgmQbuw "Generally data filters are applied after absolute ACLs (also sometimes called table-level ACLs), and after row-level ACLs. They are applied by default, and can be impactful to system behavior if not used carefully.") for a list of the default security data filters. Security data filters are applied only to GlideRecordSecure, GlideRecordSandbox and GlideAggregateSandbox queries by default. There are two new GlideRecord APIs `enableSecurityFeature` and `disableSecurityFeature` that can be used in both Java and server-side scripts to enable or disable data filters for a specific query. Important: You should explicitly enable data filters for user-facing queries that are not using GlideRecordSecure. ## When to use security data filters {#security-data-filters__section_dqx_2c1_b2c} Security data filters are best suited to: * Prevent sensitive data from leaving the database * Suppress the "rows hidden by security" message * Prevent sensitive data from leaking through reports {#security-data-filters__ul_avs_p31_b2c} ## When not to use security data filters {#security-data-filters__section_bgh_k3r_c2c} Security data filters should not be used: * As visibility control * As replacement for ACLs * With a large number of filter conditions * On unindexed columns {#security-data-filters__ul_ym5_l3r_c2c} ## Security data filter behavior {#security-data-filters__section_shr_phr_c2c} Multiple security data filters combine together for evaluation, like an `AND` combines operands. As an example,given three security data filters: * Filter 1: \`active=true * Filter 2: `priority=1` * Filter 3: `state=open` {#security-data-filters__ul_ulb_tkr_c2c}And an initial query: SELECT * FROM task WHERE state != closed AND active = true AND priority = 1 The final query is: SELECT * FROM task WHERE state != closed AND active = true AND priority = 1 AND state = open See the diagram below for a visual representation of this example: One important difference in how security data filters and ACLs are applied is, data filters on a child table do not apply to the parent table when data is queried from the parent table. Add a data filter on both child and parent tables to restrict access to records in the parent table. The diagram below highlights the hierarchy: Note: A common solution for this is to add a data filter on the parent that completely hides child records in the parent table. Data filters are applied with scoping rules similar to ACLs, but with some key differences because data filters apply before-query.