---
sourceDocument: Australia Platform security
sourceDocumentLink: https://www.servicenow.com/docs/r/australia/platform-security

 Release :

    - australia

ft:locale :

    - en-US

ft:publication_title :

    - Australia Platform security

ft:clusterId :

    - psec

bundleId :

    - psec

workflow :

    - Platform


---

# Enforce field-level ACLs on records created from the query string of the Filtered List view UI of a table

# Enforce field-level ACLs on records created from the query string of the Filtered List view UI of a table {#ariaid-title1}

Release version: Australia  
Updated March 12, 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 Enforce field-level ACLs on records created from the query string of the Filtered List view UI of a table

This feature enables ServiceNow customers to enforce field-level Access Control Lists (ACLs) when new records are created from the filtered list view UI of a table using query string parameters.
By default, field values from list filters are applied directly to new records, which can bypass ACLs and potentially allow unauthorized users to set protected fields.
Show full answer Show less  
The system property **com.glide.aclcheckallfilteronnew** controls whether ACLs are evaluated on these fields during record creation, enhancing security by preventing unauthorized field value assignments.

## How It Works

* When a new record is created from a filtered list view, field values from the filter query string are applied to the new record's fields.
* If **com.glide.aclcheckallfilteronnew** is set to **true**, field-level ACLs are enforced on all fields to ensure proper permissions before applying these values.
* There are specific dictionary attribute exceptions that modify this behavior:
  * **ignorefilteronnew**: Field values from the filter query string are ignored during record creation.
  * **aclcheckfilteronnew**: Forces ACL checks on the field during record creation.
  * **allowfilteronnew**: Skips ACL checks on the field during record creation.
* System domain fields and domain-determining fields for tables are excluded from ACL checks in this context.
* Fields with types listed in **com.glide.ignorefilteronnew.fieldtypes** still require ACL checks.

## Key Configuration Details

* **Property name:** com.glide.aclcheckallfilteronnew
* **Type:** System Property (Boolean)
* **Recommended value:** true (to enforce ACL checks)
* **Default value:** false (no ACL enforcement, potential security risk)

## Why This Matters

If **com.glide.aclcheckallfilteronnew** is set to **false** , ACLs are not checked during record creation from filtered list views, which can lead to security risks by allowing users without proper create access to set restricted fields. Setting this property to **true** closes this gap by enforcing ACLs, helping maintain data integrity and security compliance.

## Practical Recommendations for ServiceNow Customers

* Set **com.glide.aclcheckallfilteronnew** to **true** to ensure field-level security controls are applied when creating records via filtered list views.
* Review dictionary attributes on fields to understand exceptions and customize ACL enforcement where necessary.
* Be aware that enabling this property may prevent some filter-based field values from being applied if ACLs restrict the current user, which is intended behavior to maintain security.  
Use a system property to prevent list filters from affecting the initial values of created records.
Use the com.glide.acl_check_all_filter_on_new system property to ensure field level ACLs are evaluated when query string parameters are applied during the creation of new table records triggered from the
UI.

When a new record is created from the list view UI of a table, the field values included in the filter query string are applied to the new record.

For example, using this filter:

    author={62826bf03710200044e0bfc8bcbe5df1}^state={3}

The Author field is assigned the value <kbd class="ph userinput">62826bf03710200044e0bfc8bcbe5df1</kbd> and State is assigned the value <kbd class="ph userinput">3</kbd>, regardless of their default
value. The com.glide.acl_check_all_filter_on_new property ensures that field level ACLs are evaluated for all fields when a record is created from the filtered list view UI of a table. There are exceptions to
this property, which are applied in the following order:

1. If the ignore_filter_on_new dictionary attribute is set for a field, then the value of that field in a filter query string is never used in record creation from the filtered list view UI of a table.
2. If the acl_check_filter_on_new dictionary attribute is set for a field, then ACLs must be checked for that field on record creation from the filtered list view UI of a table.
3. If the allow_filter_on_new dictionary attribute is set for a field, then ACLs aren't checked for that field on record creation from the filtered list view UI of a table.
4. The sys_domain field and other domain fields specific to a table and defined by the glide.sys.domain.domain_determining_field.{table_name} property aren't checked by ACLs on record creation from the filtered list view UI of a table.
5. If the com.glide.acl_check_all_filter_on_new system property is set to <kbd class="ph userinput">true</kbd>, then ACLs must be checked for all other fields on record creation from the filtered list view UI of a table.
6. If a field's type is listed in the com.glide.ignore_filter_on_new.field_types system property, then ACLs must be checked for that field on record creation from the filtered list view UI of a table.

{#sc-enforce-field-level-acls-on__ol_tkz_x11_b3c}

Ensure that the com.glide.acl_check_all_filter_on_new system property is set to <kbd class="ph userinput">true</kbd>.

## More information {#sc-enforce-field-level-acls-on__section_wc1_cqn_phc}

{#sc-enforce-field-level-acls-on__table_ajc_b43_3kb__entry__2}

| Attribute | Description |
|-|-|
| Configuration name | com.glide.acl_check_all_filter_on_new |
| Configuration type | System Properties (/sys_properties_list.do) |
| Data type | Boolean |
| Recommended value | true |
| Default value | false |
| Fallback value | false |
| Category | [Access control](https://www.servicenow.com/docs/UcoTP53NgzpgtyyAIm1CdQ "The access control category audits the process of protecting resources from unauthorized access through granting and denying requests based on a permission model. This includes ensuring an entity accessing a resource holds valid credentials to do so, creating and protecting a well-defined set of roles or permissions and ensuring role or permission controls are protected from replay and tampering.") |
| Security risk | * Severity score: 4.8 * CVSS score: Medium * Security risk details: When com.glide.acl_check_all_filter_on_new is set to <kbd class="ph userinput">false</kbd>, then ACLs aren't checked for fields on new record creation from the filtered list view UI of a table, unless one of the other exceptions applies. In such a situation, ACLs can be bypassed by users without create access to fields. This allows protected fields to be set to improper values on record creation through the filtered list view UI of a table. {#sc-enforce-field-level-acls-on__ul_g1g_3sf_xwb} |
| Functional impact | When com.glide.acl_check_all_filter_on_new is set to <kbd class="ph userinput">true</kbd>, then ACLs may prevent fields included in the filter query string from affecting the value of fields in a created record when the creation is triggered from the list view UI of a table. However, this previous behavior was incorrect as it bypassed ACLs and allowed user without creation access to a field to modify its value. |
| Dependencies and prerequisites | None |
[ ]

{#sc-enforce-field-level-acls-on__table_ajc_b43_3kb}

