---
sourceDocument: Yokohama Governance, Risk, and Compliance
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/yokohama/governance-risk-compliance

 Release :

    - yokohama

ft:locale :

    - en-US

ft:publication_title :

    - Yokohama Governance, Risk, and Compliance

ft:clusterId :

    - grc

bundleId :

    - grc

workflow :

    - Technology


---

# Define extension rules for policy exceptions

# Define extension rules for policy exceptions {#ariaid-title1}

* Release version: Yokohama
* 
* Updated September 19, 2025
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 3 minutes to read

Enable the GRC Approval Configurator from the Policy and Compliance Properties page to allow multiple approvers for policy extension approvals, replacing the single default approver (Compliance Manager).

## Before you begin

Role required: sn_compliance.manager to create the policy exception approval rules.

## About this task

Extension rules govern how requests to prolong an existing policy exception are reviewed and approved. Using the GRC Approval Configurator, organizations can define tailored workflows for these extensions, including assigning
multiple approvers, setting dynamic conditions, and automating routing based on record data. This configuration allows multiple approvers to be designated, thereby overcoming the previous constraint of relying on a single
default approver, namely the Compliance Manager.

## Procedure

1. Navigate to AllAssignment and Approval ConfigurationsApproval Configurations.  
   The GRC Approval Configurator is shipped with default template for approval called Policy Exception - Extension Config.
2. Select Policy Exception - Approval Config.
3. On the form, fill in the fields.  
   {#define-policy-exception-extension-rules__table_klc_gq4_plb__entry__2}

   | Field | Description |
   |-|-|
   | Active | Option to enable the configuration. |
   | Filter Condition | Filter conditions to define when the configuration should be activated. The available values are sourced from the Policy Exception table. By default, State is set to Approved, and Substate to Under review. These are mandatory conditions. You can set other filter conditions as well. Use logical operators such as AND or OR to build complex condition sets. |
   | Name | Name of the approval configuration. By default, the template name is Policy Exception - Extension Config. You can change the template name. |
   | Domain | Functional group or role that should be associated with the approval flow. |
   | Priority | By default, the approval configuration is set with priority 2. Note: The approval configuration is set to priority 2 by default and should be retained to ensure that this approval triggers immediately after verification of policy exception requests. |
   | Applies to | Verify that the Policy exception (sn_compliance_policy_exception) option is selected. |
   [Table 1. Approval Configuration form]

   {#define-policy-exception-extension-rules__table_klc_gq4_plb}
4. Add approval levels to the configuration in the Approval Levels table.  
   A default approval level called Extension Approval - Level 1 is already set up. You can add multiple levels for the configuration. Each level can have its own rules, assigned users or groups, and triggering conditions.
5. Select Extension Approval - Level 1.
6. On the form, change the following fields:  
   {#define-policy-exception-extension-rules__table_zgr_qyx_rgc__entry__2}

   | Field | Description |
   |-|-|
   | Name | By default, the name provided is Extension Approval - Level 1. You can retain the same name or change the name. |
   | Level | Keep the level as 1, as this is the first level that we are configuring. |
   [Table 2. Verification Level form]

   {#define-policy-exception-extension-rules__table_zgr_qyx_rgc}
7. Select Submit.
8. Add additional approval levels to the configuration by selecting New in the Approval Levels table.  
   {#define-policy-exception-extension-rules__table_wmb_jzx_rgc__entry__2}

   | Field | Description |
   |-|-|
   | Name | Provide a name to the new level. |
   | Level | Assign the level. |
   [Table 3. Verification Level form]

   {#define-policy-exception-extension-rules__table_wmb_jzx_rgc}
9. Select Submit.  
   After adding the required approval levels, add verification rules to each level.
10. To add verification rules, select the configured verification level, and do the following:
    1. In Approval Rules, select New.
    2. On the form, fill in the fields.  
       {#define-policy-exception-extension-rules__table_ecj_kkz_bgc__entry__2}

       | Field | Description |
       |-|-|
       | Name | Name for this rule. |
       | Description | Description for the rule. |
       | Source | Source table for rule evaluation. |
       | Additional condition | Option to refine the source table by applying additional filters. |
       | Query using field | Field on the source record to query for matching approval conditions. |
       | Approve type | Approval type options: * Specific approvers: Select individual users, groups, or both as approvers directly. This option enables you to assign approvers manually without relying on dynamic or source-based logic. * Approver from source: Select approvers that are based on values from the source table. You can select a user field, a group field, or both to determine approvers dynamically from the source record. * Dynamic approvers: Define approvers dynamically using the source. Apply static or advanced dynamic conditions to filter approvers. You can select a user field, group field, or both to determine who should approve. * Scripted approvers: Use a script to determine the approvers programmatically. The script must populate the users and groups variables. {#define-policy-exception-extension-rules__ul_ibb_yf1_cgc} |
       | Approval required from | Approval options: Select All to make it required for all the selected users to approve the exception. Select Anyone to enable a single user to approve on behalf of all approvers. |
       [Table 4. Rule configuration form]

       {#define-policy-exception-extension-rules__table_ecj_kkz_bgc}
    3. Select Submit.
    {#define-policy-exception-extension-rules__substeps_y5x_d1y_rgc}
{#define-policy-exception-extension-rules__steps_bvd_5gy_rgc}

*[\>]: and then