Product documentation Docs
    • English
    • Deutsch
    • 日本語
    • 한국어
    • Français
  • More Sites
    • Now Community
    • Developer Site
    • Knowledge Base
    • Product Information
    • ServiceNow.com
    • Training
    • Customer Success Center
    • ServiceNow Support Videos
  • Log in

Product documentation

  • Home
How search works:
  • Punctuation and capital letters are ignored
  • Special characters like underscores (_) are removed
  • Known synonyms are applied
  • The most relevant topics (based on weighting and matching to search terms) are listed first in search results
Topics are ranked in search results by how closely they match your search terms
  • A match on the entire phrase you typed
  • A match on part of the phrase you typed
  • A match on ALL of the terms in the phrase you typed
  • A match on ANY of the terms in the phrase you typed

Note: Matches in titles are always highly ranked.

  • Release version
    Table of Contents
    • Now Platform administration
Table of Contents
Choose your release version
    Home Orlando Now Platform Administration Now Platform administration Platform security Access control list rules

    Access control list rules

    • Save as PDF Selected topic Topic & subtopics All topics in contents
    • Unsubscribe Log in to subscribe to topics and get notified when content changes.
    • Share this page

    Access control list rules

    Rules for access control lists (ACLs) restrict access to data by requiring users to pass a set of requirements before they can interact with it.

    Components of ACLs

    All access control list rules specify:
    • The object and operation being secured
    • The permissions required to access the object

    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.

    For example, all these entries specify an object:

    Type Name Object secured
    record [incident].[-- None --] The Incident table.
    record [incident].[active] The Active field in the Incident table.
    REST_Endpoint user_role_inheritance The record for the user_role_inheritance Scripted REST API.

    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:

    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.
    The permissions specify when someone can access the named object and operation. Security administrators can specify permission requirements by adding:
    • One or more user roles to the Requires role list.
    • One or more conditions.
    • A script that evaluates to true or false or sets the answer variable to true or false.

    To gain access to an object and operation, a user must pass all permissions listed in an access control. For example, this access control restricts access to write operations on the incident table.

    example ACL

    To update a record in the incident table, a user must have the listed role and the record must meet the condition.

    Permission type Requirement Description
    Requires role itil Only allow users with the itil role to update incidents.
    Condition [Incident state] [is not] [Closed] Only allow updates to active incident records.

    ACL evaluation process

    An ACL rule only grants a user access to an object if the user meets all of the permissions required by the matching ACL rule.

    • 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 ACL rules only] The matching table-level and field-level ACL rules must both evaluate to true.
    Figure 1. ACL evaluate permissions
    ACL evaluate permissions

    Whenever a session requests data, the system searches for access control rules that match the requested object and operation. If there is a matching access control rule, then the system evaluates if the user has the permissions required to access the object and operation. If an access control rule specifies more than one permission, then the user must meet all permissions to gain access to the object and operation. Failing any one permission check prevents the user from accessing the matching object and operation.

    If a user does not meet the permissions of the first matching rule, the system evaluates the permissions of the next matching access control rule as specified by the access control processing order. If the user fails to meet the permissions of any matching access control rule, the system denies access to the requested object and operation.
    Note: If there are no matching access control rules 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 rules because the system has a set of default access control rules that protect all record operations.

    The effects of being denied access to an object depend on the ACL rule that the user failed. For example, failing a read operation ACL rule prevents the user from seeing the object. Depending on the object secured, the ACL rule hides a field on a form, hides rows from a list, or prevents a user from accessing a UI page. The following table contains complete list of results of failing an ACL rule for a given operation and object type.

    Operation Results of failing an ACL rule on object
    execute User cannot execute scripts on a record or UI page.
    create User cannot 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 always evaluates as false. Fields on new records are considered empty until the record is saved.

    read User cannot see the object in forms or lists. The user also cannot retrieve records using API protocols such as web services.
    write User sees a read-only field in forms and lists, and the user cannot update records using API protocols such as web services.
    delete User cannot see the Delete UI action from forms. The user also cannot 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 cannot view or personalize specific columns in the list mechanic.
    list_edit User cannot update records (rows) from a list.
    report_on User cannot create a report on the ACL table. For more information, see Restrict report creation with an ACL rule.
    report_view User cannot view the content of a report on the ACL table or on the ACL field. For more information, see Restrict report creation with an ACL rule.
    personalize_choices User cannot right-click a choice list field and select Configure Choices.

    ACL matching requirements for objects

    Object Type Matching ACL Rules Required to Access Object Existing Wildcard ACL Rules
    Client-callable script includes Users must meet the permissions of two ACL rules:
    1. All wildcard ACL rules for the object (if any ACL rule exists for the operation).
    2. The first ACL rule that matches the object's name (if any ACL rule exists for the operation).
    By default, there are no wildcard (*) rules for these object types. If you create a wildcard ACL rule for one of these objects, then the ACL rule applies to all objects of this type.
    Processors
    UI pages Users must meet the permissions of two ACL rules:
    1. The first ACL rule that matches the record's field (if any ACL rule exists for the operation).
    2. The first ACL rule that matches the record's table (if any ACL rule exists for the operation).
    By default, there are wildcard table rules (*) for the create, read, write, and delete operations and wildcard field rules (*.*) for the personalize_choices, create, and save_as_template operations. When you create a new table, create new ACL rules for the table unless you want to use the provided wildcard ACL rules.
    Record
    Note: The Security manager default behavior (glide.sm.default_mode) property determines whether users can access objects that only match against wildcard table ACL rules. When this property is set to Deny access, only administrators can access objects that match the wildcard table ACL rules.
    Note: The wildcard field ACL rule (*.*) for the create operation reuses the same permissions as the write operation. This means that the create permissions are the same as the write permissions unless you define an explicit create operation ACL rule.

    Multiple ACL rules at the same point in the processing order

    If two or more rules match at the same point in the processing order, the user must pass any one of the ACL rules permissions to access the object. For example, if you create two field ACL rules 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 rule at the same point in the processing order.

    Required role

    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 for instructions.

    ACL rules in scoped applications

    You can create ACL rules for objects in the same scope as the ACL rule and for tables with at least one field that is in the same scope as the ACL rule.

    For tables that are in a different scope than the ACL rule record, the types of rules are limited.
    • You can create an ACL rule for any table, UI page, or other object that is in the same scope as the ACL rule.
    • You can create an ACL for a field that is in the same scope as the ACL rule.
      • If the table is in the same scope, you can use a script to evaluate permissions.
      • If the table is in a different scope, you cannot use a script to evaluate permissions.
    • You cannot create or modify ACL rules for objects that are in a different scope than the application you have selected in the application picker, including adding a role to an ACL in a different scope.
    • You can create wildcard table rules (*) only in the global scope.
    • You can create wildcard field rules (*) only for tables in the same scope as the ACL rule.
    • ACL rule types

      Create ACL rules on different components of the system.

    • Create an ACL rule

      Create a custom ACL rule to secure access to new objects or to change the default security behavior.

    • Contextual Security Manager

      Contextual Security Manager protects your data by controlling read, write, create, and delete authorization.

    • Advanced ACL configuration

      In addition to creating new ACLs or modifying existing ones, you can configure other aspects of ACL functionality.

    Tags:

    Feedback
    On this page

    Previous topic

    Next topic

    • Contact Us
    • Careers
    • Terms of Use
    • Privacy Statement
    • Sitemap
    • © ServiceNow. All rights reserved.

    Release version
    Choose your release version

      Access control list rules

      • Save as PDF Selected topic Topic & subtopics All topics in contents
      • Unsubscribe Log in to subscribe to topics and get notified when content changes.
      • Share this page

      Access control list rules

      Rules for access control lists (ACLs) restrict access to data by requiring users to pass a set of requirements before they can interact with it.

      Components of ACLs

      All access control list rules specify:
      • The object and operation being secured
      • The permissions required to access the object

      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.

      For example, all these entries specify an object:

      Type Name Object secured
      record [incident].[-- None --] The Incident table.
      record [incident].[active] The Active field in the Incident table.
      REST_Endpoint user_role_inheritance The record for the user_role_inheritance Scripted REST API.

      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:

      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.
      The permissions specify when someone can access the named object and operation. Security administrators can specify permission requirements by adding:
      • One or more user roles to the Requires role list.
      • One or more conditions.
      • A script that evaluates to true or false or sets the answer variable to true or false.

      To gain access to an object and operation, a user must pass all permissions listed in an access control. For example, this access control restricts access to write operations on the incident table.

      example ACL

      To update a record in the incident table, a user must have the listed role and the record must meet the condition.

      Permission type Requirement Description
      Requires role itil Only allow users with the itil role to update incidents.
      Condition [Incident state] [is not] [Closed] Only allow updates to active incident records.

      ACL evaluation process

      An ACL rule only grants a user access to an object if the user meets all of the permissions required by the matching ACL rule.

      • 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 ACL rules only] The matching table-level and field-level ACL rules must both evaluate to true.
      Figure 1. ACL evaluate permissions
      ACL evaluate permissions

      Whenever a session requests data, the system searches for access control rules that match the requested object and operation. If there is a matching access control rule, then the system evaluates if the user has the permissions required to access the object and operation. If an access control rule specifies more than one permission, then the user must meet all permissions to gain access to the object and operation. Failing any one permission check prevents the user from accessing the matching object and operation.

      If a user does not meet the permissions of the first matching rule, the system evaluates the permissions of the next matching access control rule as specified by the access control processing order. If the user fails to meet the permissions of any matching access control rule, the system denies access to the requested object and operation.
      Note: If there are no matching access control rules 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 rules because the system has a set of default access control rules that protect all record operations.

      The effects of being denied access to an object depend on the ACL rule that the user failed. For example, failing a read operation ACL rule prevents the user from seeing the object. Depending on the object secured, the ACL rule hides a field on a form, hides rows from a list, or prevents a user from accessing a UI page. The following table contains complete list of results of failing an ACL rule for a given operation and object type.

      Operation Results of failing an ACL rule on object
      execute User cannot execute scripts on a record or UI page.
      create User cannot 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 always evaluates as false. Fields on new records are considered empty until the record is saved.

      read User cannot see the object in forms or lists. The user also cannot retrieve records using API protocols such as web services.
      write User sees a read-only field in forms and lists, and the user cannot update records using API protocols such as web services.
      delete User cannot see the Delete UI action from forms. The user also cannot 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 cannot view or personalize specific columns in the list mechanic.
      list_edit User cannot update records (rows) from a list.
      report_on User cannot create a report on the ACL table. For more information, see Restrict report creation with an ACL rule.
      report_view User cannot view the content of a report on the ACL table or on the ACL field. For more information, see Restrict report creation with an ACL rule.
      personalize_choices User cannot right-click a choice list field and select Configure Choices.

      ACL matching requirements for objects

      Object Type Matching ACL Rules Required to Access Object Existing Wildcard ACL Rules
      Client-callable script includes Users must meet the permissions of two ACL rules:
      1. All wildcard ACL rules for the object (if any ACL rule exists for the operation).
      2. The first ACL rule that matches the object's name (if any ACL rule exists for the operation).
      By default, there are no wildcard (*) rules for these object types. If you create a wildcard ACL rule for one of these objects, then the ACL rule applies to all objects of this type.
      Processors
      UI pages Users must meet the permissions of two ACL rules:
      1. The first ACL rule that matches the record's field (if any ACL rule exists for the operation).
      2. The first ACL rule that matches the record's table (if any ACL rule exists for the operation).
      By default, there are wildcard table rules (*) for the create, read, write, and delete operations and wildcard field rules (*.*) for the personalize_choices, create, and save_as_template operations. When you create a new table, create new ACL rules for the table unless you want to use the provided wildcard ACL rules.
      Record
      Note: The Security manager default behavior (glide.sm.default_mode) property determines whether users can access objects that only match against wildcard table ACL rules. When this property is set to Deny access, only administrators can access objects that match the wildcard table ACL rules.
      Note: The wildcard field ACL rule (*.*) for the create operation reuses the same permissions as the write operation. This means that the create permissions are the same as the write permissions unless you define an explicit create operation ACL rule.

      Multiple ACL rules at the same point in the processing order

      If two or more rules match at the same point in the processing order, the user must pass any one of the ACL rules permissions to access the object. For example, if you create two field ACL rules 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 rule at the same point in the processing order.

      Required role

      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 for instructions.

      ACL rules in scoped applications

      You can create ACL rules for objects in the same scope as the ACL rule and for tables with at least one field that is in the same scope as the ACL rule.

      For tables that are in a different scope than the ACL rule record, the types of rules are limited.
      • You can create an ACL rule for any table, UI page, or other object that is in the same scope as the ACL rule.
      • You can create an ACL for a field that is in the same scope as the ACL rule.
        • If the table is in the same scope, you can use a script to evaluate permissions.
        • If the table is in a different scope, you cannot use a script to evaluate permissions.
      • You cannot create or modify ACL rules for objects that are in a different scope than the application you have selected in the application picker, including adding a role to an ACL in a different scope.
      • You can create wildcard table rules (*) only in the global scope.
      • You can create wildcard field rules (*) only for tables in the same scope as the ACL rule.
      • ACL rule types

        Create ACL rules on different components of the system.

      • Create an ACL rule

        Create a custom ACL rule to secure access to new objects or to change the default security behavior.

      • Contextual Security Manager

        Contextual Security Manager protects your data by controlling read, write, create, and delete authorization.

      • Advanced ACL configuration

        In addition to creating new ACLs or modifying existing ones, you can configure other aspects of ACL functionality.

      Tags:

      Feedback

          Share this page

          Got it! Feel free to add a comment
          To share your product suggestions, visit the Idea Portal.
          Please let us know how to improve this content

          Check any that apply

          To share your product suggestions, visit the Idea Portal.
          Confirm

          We were unable to find "Coaching" in Jakarta. Would you like to search instead?

          No Yes
          • Contact Us
          • Careers
          • Terms of Use
          • Privacy Statement
          • Sitemap
          • © ServiceNow. All rights reserved.

          Subscribe Subscribed Unsubscribe Last updated: Tags: January February March April May June July August September October November December No Results Found Versions Search preferences successfully updated My release version successfully updated My release version successfully deleted An error has occurred. Please try again later. You have been unsubscribed from all topics. You are now subscribed to and will receive notifications if any changes are made to this page. You have been unsubscribed from this content Thank you for your feedback. Form temporarily unavailable. Please try again or contact  docfeedback@servicenow.com  to submit your comments. The topic you requested does not exist in the release. You were redirected to a related topic instead. The available release versions for this topic are listed There is no specific version for this documentation. Explore products Click to go to the page. Release notes and upgrades Click to open the dropdown menu. Delete Remove No selected version Reset This field is required You are already subscribed to this topic Attach screenshot The file you uploaded exceeds the allowed file size of 20MB. Please try again with a smaller file. Please complete the reCAPTCHA step to attach a screenshot
          Log in to personalize your search results and subscribe to topics
          No, thanks Login