--- 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 --- # Explore Access Control Lists # Explore Access Control Lists {#ariaid-title1} Release version: Brazil Updated September 10, 2026 ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 10 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 Explore Access Control Lists Access Control Lists (ACLs) in ServiceNow are essential for securing objects such as tables, fields, records, UI pages, and scripted REST APIs by defining who can perform specific operations on them. ACLs specify the decision type, the object being secured, and the conditions required for access. This enables granular access control that enforces security policies and protects data integrity across the platform. Show full answer Show less ## Key Features * **Decision Types:** ACLs either allow access if conditions are met (*Allow-If* ) or deny access unless conditions are met (*Deny-Unless*). * **Objects Secured:** ACLs apply to specific objects identified by type and name, including tables, fields, records, UI pages, and REST endpoints. The *Applies-to* field allows ACLs to target specific records for fine-grained control. * **Operations:** Common operations controlled by ACLs include create, read, write, delete, execute, and others relevant to the object type. * **Conditions for Access:** Access is governed by required user roles, security attributes (e.g., authenticated user), data conditions based on record values, and scripts returning true/false. All specified conditions must be met for access to be granted. * **Applies-to vs Data Condition:** *Applies-to* determines if an ACL applies to certain records, while data conditions evaluate access for already matched records, enabling layered security checks. * **Deny by Default:** An empty or invalid ACL denies access by default, ensuring no unintended access occurs due to misconfiguration or missing roles/security attributes. * **ACL Evaluation Process:** The system evaluates the ACLs in order, checking roles, scripts, and conditions. Access is allowed only if all conditions in one matching ACL are met; otherwise, access is denied. * **Pre and Post Query ACL Checks:** Pre-query checks verify role-based field access before database queries, while post-query checks evaluate record-specific conditions and scripts. * **Effects of Access Denial:** Denied access results in hidden fields, rows, UI actions, or inability to perform operations via UI or APIs, depending on the failed ACL operation. * **Multiple ACLs and Wild-card Rules:** Users must pass at least one ACL at the same processing point. Wild-card ACLs () apply broadly but are restricted to certain object types and scopes. * **Scoped Applications:** ACLs can be created within the same scope or for objects in the same scope. Scripts in ACLs are restricted when targeting objects in different scopes. Wild-card table ACLs can only be created in the global scope. * **Role Requirements:** Only users with the *securityadmin* role can create or modify ACLs; normal admins can view and debug them. ## Practical Implications for ServiceNow Customers Understanding and correctly configuring ACLs is critical to securing ServiceNow instances. Customers should: * Use ACLs to precisely control access to sensitive tables, fields, and records based on roles, attributes, and data conditions. * Leverage the *Applies-to* field for granular record-level security and use scripts for complex access logic when within the same application scope. * Regularly audit ACLs for invalid or missing roles to avoid unintended access denials. * Be aware of the default deny behavior on empty or invalid ACLs to prevent unexpected permission issues. * Test ACL effects thoroughly, including pre- and post-query checks, to confirm that users see and can interact with only authorized data and UI elements. * Maintain proper role assignments, especially for security administrators responsible for ACL management. * Understand wild-card ACL limitations and use them cautiously, particularly in scoped applications. By applying these principles, ServiceNow customers can ensure robust, flexible, and maintainable security controls that protect their data and operations effectively. Explore access control lists (ACLs). All access control lists specify: * The decision type, rule type and operation which defines the ACL * The object being secured * The conditions required to access the object {#exploring-access-control-list__ul_llr_5q3_yv} ## Components of an ACL {#exploring-access-control-list__section_ufz_ycs_dcc} The decision type defines whether users are allowed to access the object if conditions are met, or denies access to the object unless conditions are met. {#exploring-access-control-list__table_cvk_c2s_dcc__entry__2} | Decision type | Description | |-|-| | Deny-Unless | Restrict access to resource by explicitly denying access unless conditions are passed. See [Deny-Unless ACL](https://www.servicenow.com/docs/E_KuI3OCo6mLVpl~45DyaA "Learn details about Deny-Unless ACLs.") for more information. | | Allow-If | Allow access to resource if conditions are passed. | [ ] {#exploring-access-control-list__table_cvk_c2s_dcc} The object is the target to which access needs to be controlled. Each object consists of a type and name that uniquely identifies a particular table, field, or record. With the Applies-to field users have granular control over which specific records this ACL will apply to. For example, all these entries specify an object: {#exploring-access-control-list__table_mlr_5q3_yv__entry__3} | Type | Name | Object secured | |-|-|-| | record | \[incident\].\[--None--\] | The Incident table. | | record | \[incident\].\[active\] | The Active field in the Incident table. | | record | \[incident\] Applies-To: Priority = P1 | Only Priority 1 incidents in the incident table. | | REST_Endpoint | user_role_inheritance | The record for the user_role_inheritance Scripted REST API. | [ ] {#exploring-access-control-list__table_mlr_5q3_yv} Each operation describes a valid action the system can take on the specified object. Some objects, such as records, support multiple operations, while other objects, such as a REST_Endpoint, only support one operation. For example, all these entries specify an operation: {#exploring-access-control-list__table_zqf_2qx_ktb__entry__4} | Type | Name | Operation | Operation secured | |-|-|-|-| | record | \[incident\].\[-- None --\] | create | Creating records in the Incident table. | | record | \[incident\].\[active\] | write | Updating the Active field in the Incident table. | | REST_Endpoint | user_role_inheritance | execute | Running the user_role_inheritance scripted REST API. | [ ] {#exploring-access-control-list__table_zqf_2qx_ktb} The conditions specify when someone can access the named object and operation. Security administrators can specify condition requirements by adding: * One or more user roles to the Requires role list. * One or more security attributes need to be evaluated to be true. * One or more data conditions. * A script that evaluates to true or false or sets the `answer` variable to true or false. {#exploring-access-control-list__ul_olr_5q3_yv} To gain access to an object and operation, a user must pass all conditions listed in an access control. For example, this access control restricts access to view operations on the incident table. To update a record in the incident table, a user must have the listed roles and the record must meet the condition. {#exploring-access-control-list__table_n55_qsx_ktb__entry__3} | Condition type | Requirement | Description | |-|-|-| | Requires role | Requires role:itil | Only allow users with the itil role to update incidents. | | Security Attributes | UserIsAuthenticated | Only authenticated users to update incidents. | | Data Condition | \[Incident state\] \[is not\] \[Closed\] | Only allow updates to active incident records. | [ ] {#exploring-access-control-list__table_n55_qsx_ktb} ## Applies-to behavior {#exploring-access-control-list__section_cwl_3xb_xcc} The Applies-to field determines whether an ACL applies to records, whereas data condition evaluates an ACL that's already applied. Applies-to specifies whether the ACL affects a specific record; if it's empty, the ACL applies to all records. Applies-to can be used for granular ACL enforcement whereas "Data Condition" is an evaluation criteria. Note: Applies-to is case sensitive. ## Deny by default behavior {#exploring-access-control-list__section_wny_qnl_zbc} By default the ACL engine completely denies access if an ACL is empty or invalid. Empty ACLs are defined as ACLs without one or more of these components: * Defined role * Security attribute * Data condition * Script {#exploring-access-control-list__ul_gbp_cns_dcc} Invalid ACLs are defined as: * ACLs with roles that do not exist (e.g. have no row in the database) * ACLs with Security Attributes that do not exist (e.g. have no row in the database) * ACLs with a script that contains "answer=true" or "true" {#exploring-access-control-list__ul_hfh_15l_zbc} Important: The system denies access when none of the roles referenced by an ACL exist on the instance. This doesn't apply to ACLs that have a mix of valid and invalid roles. You can find ACLs with invalid role references in Access Management Console to identify and remediate them. If the system detects the user creating an ACL it will prompt the user to select a role or an existing security attribute. ## ACL evaluation process {#exploring-access-control-list__section_eng_4nn_x5b} An ACL only grants a user access to an object if the user meets all conditions required by the matching ACL. * The condition must evaluate to true. * The script must evaluate to true or return an answer variable with the value of true. * The user must have one of the roles in the required roles list. If the list is empty, this condition evaluates to true. * \[Record ACLs only\] The matching table-level and field-level ACLs must both evaluate to true. {#exploring-access-control-list__ul_cjg_b22_2r} Figure 1. ACL evaluate conditions Whenever a session requests data, the system searches for ACLs that match the requested object and operation. If there's a matching ACL, then the system evaluates if the user has the conditions required to access the object and operation. If an ACL specifies more than one condition, then the user must meet all conditions to gain access to the object and operation. Failing any one condition check prevents the user from accessing the matching object and operation. If a user does not meet the conditions of the first matching ACL, the system evaluates the conditions of the next matching ACL as specified by the access control processing order. If the user fails to meet the conditions of any matching ACL, the system denies access to the requested object and operation. Note: If there are no matching ACLs for the requested object and operation, then the system grants the user access to it. In practice, it is rare for the system to find no matching ACLs because the system has a set of default ACLs that protect all record operations. The effects of being denied access to an object depend on the ACL that the user failed. For example, failing a read operation ACL prevents the user from seeing the object. Depending on the object secured, the ACL hides a field on a form, hides rows from a list, or prevents a user from accessing a UI page. The following table contains a complete list of results of failing an ACL for a given operation and object type. ## Pre and post query ACL checks {#exploring-access-control-list__section_fng_4nn_x5b} Your instance checks ACLs both before and after a user makes a query. Because different information is available before and after a query, results can be different. Pre-query ACL check : Before your instance runs a database query, it checks the ACLs for each field in the queried table to determine which fields a user may access. This check only looks at the user's roles, and checks to see if these roles allow access to fields. Because this check runs before the query, the ACL doesn't have access to the records on the table, so it can't take that data into account. Scripts and conditions that rely on knowing the contents of a record aren't evaluated. If the user doesn't have read access at this point, the value for the field isn't shown to the user. Post-query ACL check : After the query, your instance checks each record returned by the query. During this check, there's context for the ACL, so the role, condition, and script portions of the ACL are evaluated. If the user doesn't have read access at this point, the value for the field isn't shown to the user, however the user sees the field label if their roles allow access to the field. {#exploring-access-control-list__table_evh_h12_2r__entry__2} | Operation | Results of failing an ACL on object | |-|-| | execute | User can't execute scripts on a record or UI page. | | create | User can't see the New UI action from forms. The user also cannot insert records into a table using API protocols such as web services. A create ACL with a condition requiring that a field contain a specific value may evaluate as false. Fields on new records are considered empty until the record is saved. | | read | User can't see the object in forms or lists. The user also can't retrieve records using API protocols such as web services. | | write | User sees a read-only field in forms and lists, and the user can't update records using API protocols such as web services. | | delete | User cannot see the Delete UI action from forms. The user also can't remove records from a table using API protocols such as web services. | | edit_task_relations | User cannot define relationships between task tables. | | edit_ci_relations | User cannot define relationships between Configuration Item \[cmdb_ci\] tables. | | save_as_template | Used to control the fields that should be saved when a template is created. | | add_to_list | User can't view or personalize specific columns in the list mechanic. | | list_edit | User can't update records (rows) from a list. | | report_on | User can't create a report on the ACL table. For more information, see [Restrict report creation with an ACL rule](https://www.servicenow.com/docs/access?context=t_RestrictRepCreationWAnACLRule&version=brazil&pubname=brazil-now-intelligence&ft:locale=en-US). | | report_view | User can't view the content of a report on the ACL table or on the ACL field. For more information, see [Reporting](https://www.servicenow.com/docs/access?context=reporting-landing-page&version=brazil&pubname=brazil-now-intelligence&ft:locale=en-US). | | personalize_choices | User can't right-click a list field and select Configure Choices. | [ ] {#exploring-access-control-list__table_evh_h12_2r} ## ACL matching requirements for objects {#exploring-access-control-list__section_uyl_4g4_l1b} {#exploring-access-control-list__table_bcz_vb2_2r__entry__3} | Object Type | Matching ACL Rules Required to Access Object | Existing wild-card ACL Rules | |-|-|-| | Client-callable script includes | Users must meet the conditions of two ACLs: 1. All wild-card ACLs for the object (if any ACL exists for the operation). 2. The first ACL that matches the object's name (if any ACL rule exists for the operation). {#exploring-access-control-list__ol_jrf_lc2_2r} | By default, there are no wild-card (\*) rules for these object types. If you create a wild-card ACL for one of these objects, then the ACL applies to all objects of this type. | | Processors | Users must meet the conditions of two ACLs: 1. All wild-card ACLs for the object (if any ACL exists for the operation). 2. The first ACL that matches the object's name (if any ACL rule exists for the operation). {#exploring-access-control-list__ol_jrf_lc2_2r} | By default, there are no wild-card (\*) rules for these object types. If you create a wild-card ACL for one of these objects, then the ACL applies to all objects of this type. | | UI pages | Users must meet the conditions of two ACLs: 1. The first ACL that matches the record's field (if any ACL exists for the operation). 2. The first ACL that matches the record's table (if any ACL exists for the operation). {#exploring-access-control-list__ol_jfb_pc2_2r} | By default, there are wild-card table rules (\*) for the create, read, write, and delete operations and wild-card field rules (\*.\*) for the personalize_choices, create, and save_as_template operations. When you create a table, create ACLs for the table unless you want to use the provided wild-card ACLs. | | Record | Users must meet the conditions of two ACLs: 1. The first ACL that matches the record's field (if any ACL exists for the operation). 2. The first ACL that matches the record's table (if any ACL exists for the operation). {#exploring-access-control-list__ol_jfb_pc2_2r} | By default, there are wild-card table rules (\*) for the create, read, write, and delete operations and wild-card field rules (\*.\*) for the personalize_choices, create, and save_as_template operations. When you create a table, create ACLs for the table unless you want to use the provided wild-card ACLs. | [ ] {#exploring-access-control-list__table_bcz_vb2_2r} Note: The Security manager default behavior (glide.sm.default_mode) property determines whether users can access objects that only match against wild-card table ACLs. When this property is set to Deny access, only administrators can access objects that match the wild-card table ACLs. Note: The wild-card field ACL (\*.\*) for the create operation reuses the same conditions as the write operation. This means that the create conditions are the same as the write conditions unless you define an explicit create operation ACL. ## Multiple ACLs at the same point in the processing order {#exploring-access-control-list__section_b3r_dtk_t1b} If two or more ACLs match at the same point in the processing order, the user must pass any one of the ACL conditions to access the object. For example, if you create two field ACLs for incident.number, then a user who passes one rule has access to the number field regardless of whether the user failed any other field ACL at the same point in the processing order. ## Required role {#exploring-access-control-list__section_sf1_xb2_vwb} Normal admin users can view and debug access control rules. However, to create or update existing access control rules, administrators must elevate privileges to the security_admin role. See [Elevate to a privileged role](https://www.servicenow.com/docs/pOLlLS816Bs_Thh7RBuPjg "The base system admin can elevate to a privileged role to have access to the features of High Security Settings.") for instructions. ## ACLs in scoped applications {#exploring-access-control-list__section_sfv_mgn_l1b} You can create ACLs for objects in the same scope as the ACL. You can also create ACLs for tables with at least one field that is in the same scope as the ACL. For tables that are in a different scope than the ACL record, the types of ACLs are limited. * You can create an ACL for any table, UI page, or other object that is in the same scope as the ACL. * You can create an ACL for a field that is in the same scope as the ACL. * If the table is in the same scope, you can use a script to evaluate conditions. * If the table is in a different scope, you can't use a script to evaluate conditions. {#exploring-access-control-list__ul_fxr_1zd_2r} * You can't create or modify ACLs for objects that are in a different scope than the application you've selected in the application picker, including adding a role to an ACL in a different scope. * You can create wild-card table rules (\*) only in the global scope. * You can create wild-card field rules (\*) only for tables in the same scope as the ACL. {#exploring-access-control-list__ul_msq_zyd_2r}