Contextual Security Manager

  • Release version: Australia
  • Updated June 3, 2026
  • 3 minutes to read
    • Summarize
    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 Contextual Security Manager

    The Contextual Security Manager enhances data protection in ServiceNow by controlling read, write, create, and delete authorizations with greater precision. It leverages the system table hierarchy to apply security rules contextually, based on where data is displayed and the contents of records.

    Show full answer Show less

    Key Features

    • Contextual Security: Secures records dynamically based on their content.
    • Hierarchical Security: Enables security rule application at any level within the object hierarchy.
    • Field and Table Security: Moves away from role-based dictionary entry security to ACL rule-based security. After installation, securing fields and tables requires configuring ACL rules, as dictionary roles are no longer evaluated.
    • Role Management: Roles must be assigned via the Roles related list on users or groups rather than the roles field on the user record. Role requirements for applications, modules, catalog items, and variables continue to be defined by role arrays.
    • Role Inheritance: Groups inherit roles automatically if the role's inherits flag is set to true.
    • Plugins:
      • Contextual Security: Role Management (automatically installed) provides core contextual security functionality.
      • Contextual Security: Role Management V2 (for upgrades) eliminates duplicate role entries caused by inherited roles and includes auditing capabilities.
      • Role Management Enhancements is an earlier plugin version without the audit script.
    • Audit Capability: After activating Role Management V2, enable the glide.rolemanagement.v2.auditroles system property to audit user role changes.
    • Security Attribute Conditions: Starting with the Vancouver release, ACL rules support Security Attribute Conditions that evaluate user or session properties (such as group membership, authentication state, or network location) to control access. These conditions can be local to one ACL or reusable across multiple ACLs.

    Practical Implications for ServiceNow Customers

    After implementing the Contextual Security Manager, customers must:

    • Transition field and table security from dictionary-based role assignments to ACL rule configurations.
    • Assign roles through the Roles related list on user and group records, as the legacy roles field is deprecated.
    • Understand that role arrays continue to govern access to applications, modules, catalog items, and variables.
    • Consider upgrading to Role Management V2 if you encounter duplicate role entries to improve performance and enable audit capabilities.
    • Leverage Security Attribute Conditions in ACLs to create more granular and dynamic access controls based on user and session attributes.

    These changes provide more flexible, context-aware security enforcement, enabling finer control over data access and improved security auditing within your ServiceNow instance.

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

    Key advantages

    The Contextual Security Manager is aware of the system table hierarchy, enabling you to create specific security rules for a field based on where in the hierarchy it is displayed. Benefits of the Contextual Security Manager include:

    • Contextual security: Secure a record based on the contents of the record.
    • Hierarchical security: Apply security rules to any level in the object hierarchy.

    Securing fields and tables

    With the legacy Simple Security Manager, you could secure fields and tables by adding roles to the appropriate dictionary entry. With the Contextual Security Manager, these dictionary roles are no longer tested. Instead, the system looks for ACL rules on fields and tables.

    Warning:
    After you install the Contextual Security Manager, you must secure fields and tables via ACL rules. Even if you Configuring the form layout the dictionary form and add roles to a dictionary entry, no change in rights occurs.

    Contextual security and roles

    You can grant roles to users or groups. However, after installing the Contextual Security Manager, the roles field on the user record is no longer checked and no longer appears on your user and group forms. Instead, you must add roles to the Roles related list instead of to the user or group record.

    Applications and modules contain lists of the roles required to view them. For example, to view the System Definition application, the admin role is required. Security rights for applications and modules are still defined using role arrays.

    Both catalog items and catalog variables contain lists of the roles required to view them. Security rights for catalog items and catalog variables are still defined via these role arrays.

    Under the Contextual Security Manager, a group still automatically inherits any role granted to the group when the inherits flag for the role is set to true.

    Activating the Contextual Security Manager

    The Contextual Security Manager is active in the base system. If there are many duplicate entries in the User Roles table, you may need to upgrade to Contextual Security: Role Management V2 to eliminate duplicate roles. Plugins include:

    Contextual Security: Role Management [com.glide.role_management]
    Provides contextual security functionality. This plugin is automatically installed.
    Contextual Security: Role Management V2 [com.glide.role_management.inh_count]
    Prevents duplicate entries caused by inherited roles in the User Roles [sys_user_has_role] table. This plugin is automatically installed on new instances and can be activated for upgrades. The Contextual Security: Role Management Enhancements plugin is a previous version of this plugin. The Role Management Enhancements plugin does not include the RoleManagementVerify() script. This script returns a list of changes that an upgrade will perform, enabling you to monitor changes made by the plugin.
    Note:
    After activating Role Management V2, you must set the glide.role_management.v2.audit_roles system property to allow the Audit Roles table to create audit records related to user roles. To learn more about setting this property and about the Audit Roles table, see:

    Security Attribute Conditions

    Starting with the Vancouver release, ACL rules support a Security Attribute Condition type in addition to the standard role, condition, and script fields. Security Attribute Conditions evaluate properties of the current user or session, such as group membership, authentication state, or network location, to determine whether access is granted.

    Security Attribute Conditions can be defined as local or existing:

    Local
    The condition is saved only to the ACL where it is created. Conditions default to local.
    Existing
    The condition references a Security Attribute condition already defined on another ACL, enabling reuse across multiple rules.

    For a complete list of built-in security attribute types and configuration details, see Security Attributes Fundamentals and Security Attribute Type.