---
sourceDocument: オーストラリア ワークフローのビルド
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/ja-JP/build-workflows

 Release :

    - australia

ft:locale :

    - ja-JP

ft:publication_title :

    - オーストラリア ワークフローのビルド

ft:clusterId :

    - crworkflow

bundleId :

    - crworkflow

workflow :

    - Creator


---

# 「承認を求める」アクション

# 「承認を求める」アクション {#ariaid-title1}

* リリースバージョン: Australia
* 
* 更新日 2026年03月12日
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 所要時間：6分

レコードの承認を要求します。スクリプトを記述せずに承認要求を自動的に承認、却下、またはキャンセルするための一連のルールを設定します。指定された時間までに決定が下されなかった場合に自動的に承認、却下、またはキャンセルする期日を追加します。
承認は、ワークフローの進行を制御する上で中心的な役割を果たします。適切な担当者が作業を進める前にレビューして承認できるようにします。これは、インシデント処理、変更要求、カタログ履行、および構造化されたガバナンスとコンプライアンスが重要なあらゆるプロセスで不可欠です。承認の詳細については、「 [クラシックの承認](https://servicenow-prod.fluidtopics.net/Yf9ttyE1HnZ7rQxDZuqhSg "クラシック承認は、作業を行う前にタスクに対する承認を要求する従来のプロセスです。以前のリリースでは、承認レコードを作成して承認タスクを定義し、ユーザーまたはグループを関連付けて承認または却下することができました。")」を参照してください。

## ロールと可用性 {#ask-approval-flow-designer__section_pwq_rb5_kcb}

ワークフロースタジオ ServiceNow コアアクションとして利用可能です。flow_designer または admin ロールを持つユーザーは、アクションをフローに追加し、構成の詳細を定義できます。

## 入力 {#ask-approval-flow-designer__section_yyg_p4h_ccc}

フローに必要な各入力の値を指定します。動的な値を追加するには、\[データ\] パネルからピルをドラッグアンドドロップすることも、ピルピッカーから選択することもできます。

レコード
:   データタイプ：Record

    承認するレコードへの参照。レコードに承認フィールドが含まれている場合、ワークフロースタジオ は \[承認フィールド\] の入力を自動的に設定します。

テーブル
:   データタイプ：Table Name

    承認要求に関連付けられたレコードのテーブル名。選択するテーブルは、承認ステータスフィールドを保持することで、承認をサポートする必要があります。たとえば、タスクテーブルとその拡張には承認フィールドが含まれています。

承認理由
:   データタイプ：String

    承認の理由を含むテキスト文字列。このフィールドは、監査と規制コンプライアンスに使用できます。この情報は、承認 \[sysapproval_approver\] テーブルに保存されます。たとえば、個人またはグループからの特定の承認要求が必要な理由をリストできます。

承認フィールド
:   データタイプ：Field Name

    承認要求の結果を含むフィールド。

ジャーナルフィールド
:   データタイプ：Field Name

    承認要求に関連付けられた履歴とコメントを保存するフィールド。

ルール
:   データタイプ：Approval Rules

    要求を承認または却下できるユーザーと、レコードが承認または却下された後の動作を構成します。
    承認または却下のユーザールールには次のものがあります。  
    * 誰でも承認できます。リストされているユーザーが承認できる場合は、このオプションを使用します。
    * すべてのユーザーが承認します。リストされているすべてのユーザーが承認する必要がある場合は、このオプションを使用します。
    * 全員が応答し、誰でも承認できます。このオプションは、すべてのユーザーが応答する必要があるが、1 人のユーザーのみが承認する必要がある場合に使用します。
    * 承認しているユーザーの割合。このオプションは、過半数のユーザーの承認が必要な場合に使用します。
    * # 人のユーザーが承認しています。特定の数のユーザーを承認する必要がある場合は、このオプションを使用します。
    {#ask-approval-flow-designer__ul_oxw_thm_3cb}

    承認ルールの横にあるフィールドに、目的の承認ユーザーを追加します。承認ユーザーを追加するには:

    * 個々のユーザーまたはグループを選択します。
    * レコードからフィールドをドラッグまたは選択します。
    * 手動承認者 ![手動承認者アイコン]() を選択すると、手動承認者が承認または却下を処理できるようになります。手動承認者は、手動で承認者関連リストに追加されたユーザーで、これにより要求を承認できます。たとえば、内容領域専門家をタスクに手動で追加して、要求を承認することができます。手動承認者の追加について詳しくは、「[承認者関連リストを使用した承認の生成](https://servicenow-prod.fluidtopics.net/UNQxSOKjhkXg00zzf2ncyg "手動で承認者を要求に追加することができます。")」を参照してください。
    {#ask-approval-flow-designer__ul_qh4_33m_3cb}  
    注:  
    デフォルトでは、\[承認を求める\] は非アクティブなユーザーとグループの承認レコードを生成します。この動作により、特定のユーザーまたはグループが後で非アクティブになった場合でも、フローまたはアクションは引き続き機能できます。非アクティブなエンティティの承認を生成する動作を変更する場合は、com.glide.hub.flow.approval.allow_inactive_entity システムプロパティを設定します。「[ワークフロースタジオ フローシステムプロパティ](https://servicenow-prod.fluidtopics.net/VMZc4gAgS1UwgD5o~IDHxQ "フローの処理方法を設定します。")」を参照してください。

    別の OR ルールセットを追加して、却下ルールを定義します。承認を定義するときに、一致する承認がない場合に実行される却下ルールを含めます。このような却下ルールは、フローが待機状態のままになるのを防ぎます。たとえば、承認を誰でも承認できる場合は、誰もそれを承認しない場合に備えて、時間ベースの却下ルールを作成します。

    注:  
    却下ルールのない承認ルール (またはその逆) を設定し、予想される承認ステータスが満たされない場合、ランタイム値はキャンセルされます。

    インラインスクリプトを使用して承認ルールを指定する方法については、ServiceNow コミュニティのブログ投稿「[Scripted Approvals in Flow Designer with Flow Variables (フロー変数を使用したフローデザイナーのスクリプト化された承認)](https://www.servicenow.com/community/now-platform-blog/scripted-approvals-in-flow-designer-with-flow-variables/ba-p/2284506)」を参照してください。

期日
:   データタイプ： Schedule Date/Time

    フローが永久的に承認待ち状態になるのを防ぐための承認ステータスの期日。

## 出力 {#ask-approval-flow-designer__section_lky_lwh_ccc}

これらの出力は \[データ\] パネルに表示されます。フローの他の場所で入力として使用できます。{#ask-approval-flow-designer__outputs-description}

承認ステータス
:   データタイプ：Choice

    承認要求の完了ステータス。フロー実行の詳細ページには、次のいずれかの値が表示されます。

    * 未要求 \[not requested\]
    * 要求済み \[requested\]
    * 承認済み \[approved\]
    * 却下 \[rejected\]
    * キャンセル \[cancelled\]
    * 不要 \[not_required\]
    * スキップ \[skipped\]
    {#ask-approval-flow-designer__ul_epn_jjz_zmb}

## 例 {#ask-approval-flow-designer__section_yp5_sb5_kcb}

このフロー例では、新しい高優先度のインシデントが作成されるたびに、または既存のインシデントが更新されるたびに承認が必要です。インシデントがキューに入ると、フローは「承認を求める」アクションをトリガーして、アサインされた作業が適切であり、インシデントが先に進むべきであることを確認します。アクションは、標準的な IT サポート時間に合わせて、平日の 8 時から 5 時のスケジュールに従って、応答を 1 営業日待機します。その期間内に承認者が応答しない場合、サービス回復の遅延を防ぐため、要求が自動的に承認されます。

承認要求は、\[アサイン先\] フィールドにリストされているユーザーのマネージャーにルーティングされます。これにより、担当リーダーが、アサインされた技術者がインシデントを処理するための適切なスキルセットと作業負荷キャパシティを持っているかどうかを確実にレビューできます。マネージャーは 1 日以内に要求を承認または却下できます。これにより、ワークフローは決定に基づいてインシデントを続行または再ルーティングできます。

## 一般的なガイドライン {#ask-approval-flow-designer__section_iln_5f2_5vb}

承認を求めるときは、次のガイドラインに従ってください。

\[次を並列で操作 (Do the following in parallel)\] フローロジックの承認を求めるアクションを複製しない
:   ワークフロースタジオ では、\[次を並列で操作 (Do the following in parallel)\] フローロジックを使用した、同じレコードに対する複数の承認要求の作成はサポートされていません。同じレコードに対して承認を要求すると、分岐間に依存関係ができます。どの分岐が最初に完了するかわからないため、予期しない結果が生じる可能性があります。