---
sourceDocument: Australia Platform security
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/de-DE/platform-security

 Release :

    - australia

ft:locale :

    - de-DE

ft:publication_title :

    - Australia Platform security

ft:clusterId :

    - psec

bundleId :

    - psec

workflow :

    - Platform


---

# Explore Data filtration

# Explore Data filtration {#ariaid-title1}

* Freigeben Version: Australia
* 
* Aktualisiert 12. März 2026
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 2 Minuten Lesedauer

Use Data filtration to control access to tables and records based on subject attributes when performing read queries.
Data filtration is a separate form of access control designed to work along with the existing Access Control rules (ACLs) on your instance. Data filtration denies access to tables and records that do not match subject attributes
defined by an administrator. Data filtration is designed to make auditing, reporting, and troubleshooting easier.

This is an optional feature that administrators can activate on their instance.

## Data filtration features {#data-filtration__section_ygp_wl4_t4b}

Data Filters
:   Use data filters to grant access based on information within a record. Data filters use data in a tables field to determine whether a record is available to your users.

Subject attribute based condition builder
:   Use subject attributes to evaluate user role, group, subject criteria, or IP network address.

Data filtration uses a deny based model
:   Data filtration uses a deny based model to control access to records. With Data filtration, your instance denies access to records unless a record meets the criteria defined by Data filtration.

Data filtration enforcement
:   Data filtration rules run after the database query for read operations and are evaluated before ACLs. A record denied by any Data filtration rule will not proceed and be evaluated by ACL rules. Data filtration rule
    enforcement is consistent with that of read ACLs.

Data filtration and reporting

:   Data filtration and ACL's are both applied only when creating list view reports. Reporting does not apply access control when collecting aggregated data. In this case, neither Data filtration nor ACLs are checked.

    For aggregated reports, Data filtration works in conjunction with existing Report_view access control list behaviors. See [Report_view access control](https://www.servicenow.com/docs/access?context=report-view-access-control&version=australia&pubname=australia-now-intelligence&ft:locale=en-US) for further details on configuring these report controls.

Session debugging
:   Data filtration supports session debugging. Use session debugging to see which Data filtration records apply for a given query. Admins can use this information to troubleshoot user access to records.

## Components of Data filtration {#data-filtration__section_otv_bhz_x4b}

Data filtration works using the following record types:

Data filtration records
:   Create a Data filtration \[sys_df_data_filtration\] record to grant table access on your instance. The Data filtration record contains the Data filter and Subject attribute
    conditions described above to limit the scope of the rule and the affected users.

Subject criteria records
:   Subject criteria \[sys_df_subject_criteria\] records represent specific user attributes you can use to determine whether to grant access with a Data filtration rule. These attributes can be a user's groups, roles, or IP
    address. To create a subject criteria, you must create the subject criteria record, as well as criteria input and criteria conditions records. For details on this process, see [Create subject criteria](https://servicenow-prod.fluidtopics.net/UHKZcOJQ3N7YiCq2rmuxxw "Create subject criteria records for use in data filtration rules.").
:   After creating a subject criteria records, you can apply them to a rule. This is done on the Subject Condition tab of your Data filtration rule.

Criteria input records examples
:
    Abbildung : 1. Example criteria input for all roles containing admin
:   Criteria inputs \[sys_df_subject_filter_criteria_m2m\] are records that contain criteria to compare with the user. This can be a list of user groups or roles, an IP address range, or an IP address subnet. These records
    are used along with subject criteria condition records to evaluate against a user's groups, roles, or IP address to determine access to a table or it's records.

Subject criteria condition records
:
    Abbildung : 2. Example criteria condition using the Admins Only criteria input
:   Use subject criteria condition \[sys_df_subject_criteria_condition\] records to define how to compare user attributes with the roles, groups, or IP addresses defined in you criteria inputs. You can use multiple criteria
    inputs in a single subject criteria condition to further narrow down access to your records.