---
sourceDocument: Yokohama のガバナンス、リスク、コンプライアンス
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/ja-JP/yokohama/governance-risk-compliance

 Release :

    - yokohama

ft:locale :

    - ja-JP

ft:publication_title :

    - Yokohama のガバナンス、リスク、コンプライアンス

ft:clusterId :

    - grc

bundleId :

    - grc

workflow :

    - Technology


---

# ポリシー例外の拡張ルールの定義

# ポリシー例外の拡張ルールの定義 {#ariaid-title1}

* リリースバージョン: Yokohama
* 
* 更新日 2025年09月19日
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 所要時間：4分

\[ポリシーとコンプライアンスのプロパティ\] ページから GRC 承認コンフィギュレーターを有効にして、ポリシー延長承認に対して複数の承認者を許可し、単一のデフォルトの承認者 (コンプライアンスマネージャー) を置き換えます。

## 始める前に

必要なロール:ポリシー例外承認ルールを作成するための sn_compliance.manager。

## このタスクについて

延長ルールは、既存のポリシー例外を延長する要求をレビューおよび承認する方法を管理します。組織は、GRC Approval Configurator を使用して、複数の承認者のアサイン、動的条件の設定、レコードデータに基づくルーティングの自動化など、これらの拡張に合わせたワークフローを定義できます。この構成では、複数の承認者を指定できるため、1 人の既定の承認者、つまりコンプライアンスマネージャーに依存するという以前の制約を克服できます。

## 手順

1. 移動先 すべてアサイン構成および承認構成承認構成.  
   GRC Approval Configurator には、「 ポリシー例外 - 拡張構成」と呼ばれる承認用のデフォルトテンプレートが付属しています。
2. \[ポリシー例外:承認構成\] を選択します。
3. フォームで、フィールドに入力します。  
   {#define-policy-exception-extension-rules__table_klc_gq4_plb__entry__2}

   | フィールド | 説明 |
   |-|-|
   | アクティブ | 構成を有効にするオプション。 |
   | フィルター条件 | 構成をアクティブ化するタイミングを定義するフィルター条件。使用可能な値は、ポリシー例外テーブルから取得されます。 デフォルトでは、\[ステータス\] は \[承認済み\] に設定され、\[サブステート\] は \[レビュー中\] に設定されます。これらは必須条件です。 他のフィルター条件も設定できます。複雑な条件セットを作成するには、AND や OR などの論理演算子を使用します。 |
   | 名前 | 承認構成の名前。 デフォルトでは、テンプレート名は「 ポリシー例外 - 拡張構成」です。テンプレート名は変更できます。 |
   | ドメイン | 承認フローに関連付ける必要がある機能グループまたはロール。 |
   | 優先度 | デフォルトでは、承認構成は優先度 2 に設定されています。 注: 承認構成はデフォルトで優先度 2 に設定されており、ポリシー例外要求の検証直後にこの承認がトリガーされるように保持する必要があります。 |
   | 適用先 | \[ ポリシー例外 (sn_compliance_policy_exception)\] オプションが選択されていることを確認します。 |
   [表 : 1. \[承認構成\] フォーム]

   {#define-policy-exception-extension-rules__table_klc_gq4_plb}
4. \[承認レベル\] テーブルの構成に承認レベルを追加します。  
   「 拡張承認 - レベル 1 」と呼ばれるデフォルトの承認レベルが既に設定されています。構成には複数のレベルを追加できます。各レベルには、独自のルール、アサインされたユーザーまたはグループ、およびトリガー条件を設定できます。
5. \[ 延長承認:レベル 1\] を選択します。
6. フォームで、次のフィールドを変更します。  
   {#define-policy-exception-extension-rules__table_zgr_qyx_rgc__entry__2}

   | フィールド | 説明 |
   |-|-|
   | 名前 | デフォルトでは、提供される名前は「拡張承認 - レベル 1」です。 同じ名前を保持することも、名前を変更することもできます。 |
   | レベル | これは構成する最初のレベルであるため、レベルを 1 のままにします。 |
   [表 : 2. \[検証レベル\] フォーム]

   {#define-policy-exception-extension-rules__table_zgr_qyx_rgc}
7. \[送信\] を選択します。
8. \[承認レベル\] テーブルで \[ 新規 \] を選択して、構成に承認レベルを追加します。  
   {#define-policy-exception-extension-rules__table_wmb_jzx_rgc__entry__2}

   | フィールド | 説明 |
   |-|-|
   | 名前 | 新しいレベルに名前を付けます。 |
   | レベル | レベルを割り当てます。 |
   [表 : 3. \[検証レベル\] フォーム]

   {#define-policy-exception-extension-rules__table_wmb_jzx_rgc}
9. \[送信\] を選択します。  
   必要な承認レベルを追加した後、各レベルに検証ルールを追加します。
10. 検証ルールを追加するには、構成された検証レベルを選択し、次の操作を行います。
    1. \[承認ルール\] で \[ 新規\] を選択します。
    2. フォームで、フィールドに入力します。  
       {#define-policy-exception-extension-rules__table_ecj_kkz_bgc__entry__2}

       | フィールド | 説明 |
       |-|-|
       | 名前 | このルールの名前。 |
       | 説明 | ルールの説明。 |
       | ソース | ルール評価のソーステーブル。 |
       | 他の条件 | 追加のフィルターを適用してソーステーブルを絞り込むオプション。 |
       | フィールドを使用するクエリ | 一致する承認条件を照会するソースレコードのフィールド。 |
       | 承認タイプ | 承認タイプオプション: * 特定の承認者:個々のユーザー、グループ、またはその両方を承認者として直接選択します。このオプションを使用すると、動的ロジックまたはソースベースのロジックに依存せずに、承認者を手動でアサインできます。 * ソースからの承認:ソーステーブルの値に基づいて承認者を選択します。ユーザーフィールド、グループフィールド、またはその両方を選択して、ソースレコードから承認者を動的に決定できます。 * 動的承認者:ソースを使用して承認者を動的に定義します。静的または高度な動的条件を適用して承認者をフィルタリングします。ユーザーフィールド、グループフィールド、またはその両方を選択して、承認するユーザーを決定できます。 * スクリプト化された承認者:スクリプトを使用して、プログラムで承認者を決定します。スクリプトは、ユーザー変数とグループ変数を設定する必要があります。 {#define-policy-exception-extension-rules__ul_ibb_yf1_cgc} |
       | 次の承認が必要： | 承認オプション:選択したすべてのユーザーが例外を承認することを必須にするには、\[ すべて \] を選択します。1 人のユーザーがすべての承認者の代わりに承認できるようにするには、\[ 任意のユーザー\] を選択します。 |
       [表 : 4. ルール構成フォーム]

       {#define-policy-exception-extension-rules__table_ecj_kkz_bgc}
    3. \[送信\] を選択します。
    {#define-policy-exception-extension-rules__substeps_y5x_d1y_rgc}
{#define-policy-exception-extension-rules__steps_bvd_5gy_rgc}