ServiceNow ワークフローの承認アクティビティの挙動調査

# 調査したアクティビティ
公式ではWorkflowの後継機能であるFlow Designerの使用を推奨されていますが、
使い勝手や過去資源の存在からWorkflowもまだまだ現役という環境が多いのではないかと思います。
今回はCore ActivitiesのApprovalsにある

- Approval Group
- Approval User
- Approval Action
- Approval Coordinator

の動作について調べました。
尚、これらのアクティビティはTaskテーブルを拡張したテーブルでのみ仕様可能です。
<img width="300" alt="wf-pic1.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2707437/b35f851b-7607-21ac-533b-657018f266e5.png">


# Approval Actionの設定
Approval Actionの設定項目はシンプルで、Actionを４つの中から選ぶだけです。
<img width="850" alt="wf-pic2.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2707437/1f6d2b28-1e85-21ce-ee06-d43db9e164d1.png">

<dl>
  <dt>①Mark task approved</dt>
  <dd>対象レコードのApproval値を「Approved」にします</dd>
  <dt>②Mark task rejected</dt>
  <dd>対象レコードのApproval値を「Rejected」にします</dd>
  <dt>③Mark task requested</dt>
  <dd>対象レコードのApproval値を「Requested」にします</dd>
  <dt>④Disregard pending approvals</dt>
  <dd>このActivityが実施された時点でRequested状態になっている承認レコードを強制的に「Cancelled」にします</dd>
  <dd>※公式Docではno longer requiredとなっていますが、実際に動かしてみたところCancelledになるようです</dd>
</dl>

①～③はSet Valueアクティビティを用いてApprovalに値をセットするのと同じ動きになります

# Approval Userの設定
##### ①Approversの設定
Approversで誰の承認が必要かを指定します。承認者が固定されていればUserテーブルから選択。
Advancedにチェックをつければスクリプトで指定する事も可能で、下図のようにanswer配列に承認を行わせたいuser情報をpushすればOKです。
<img width="950" alt="wf-pic3.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2707437/c725e1cd-a5db-74fe-23aa-d7214c175358.png">
```javascript
answer=[];
answer.push(current.assigned_to);
```

##### ②Condition for approvalの設定
複数人承認者がいた場合、誰か1人でも承認すればよいのか、あるいは全員の承認が必要なのかや、承認拒否された際にActivity自体をRejectにするのか、他の承認者の承認を待つのか等の設定をWait forとWhen anyone rejectsで指定します。下図の設定ですと誰か1人でも承認すれば承認完了、逆に誰か1人でも拒否すれば承認拒否となります（つまり最初に承認or拒否された内容で処理が完了します）。

また、Approval ColumnとApproval Journal Columnは対象テーブルで承認情報が記録されるカラムを指定します。ここを変更する事は少ないかと思います。
<img width="950" alt="wf-pic4.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2707437/3f5e3356-02b9-5c23-f1a2-04edd9fdc47e.png">

##### ③Scheduleの設定
承認レコードの期限（Due Dateにセットされます）、スケジュール（期限のカウント条件）及び使用するタイムゾーンを設定できます。
下図の設定ですとタイムゾーンは日本時間、期限は2時間、スケジュールは平日8時～17時となります。つまり月曜16時に承認レコードが作成された場合、営業時間が考慮され期限は火曜9時となります。
ちなみに期限が切れた後でも普通に承認可能で、期限を特に設定しない場合Due Dateには承認レコードの作成日時が入るようです。
<img width="950" alt="wf-pic5.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2707437/08a03543-9d9b-dd90-fcd1-4e674d3d2888.png">

# Approval Groupの設定
Approversに入るのがGroupsになるだけで、基本的な使い方はApproval Userと同じです
<img width="950" alt="wf-pic6.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2707437/41732a94-cfa5-7244-122a-08f9f04fd815.png">

# Approval Conditionの設定
このActivityは子Activityとして

<dl>
  <dt>・Approval-Group</dt>
  <dt>・Manual Approvals</dt>
  <dt>・Approval-User</dt>
</dl>

を持たせる事ができ、Wait forで子Activityの承認/拒否に応じた処理を設定します。子Activityの設定内容は単体でActivityを追加する時と同じです。
<img width="250" alt="wf-pic7.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2707437/10c32d07-6b94-a98d-8008-84b221bb145c.png">
<img width="950" alt="wf-pic8.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2707437/3f798c92-4e6e-10cb-cbe4-42e0fb548e87.png">


# サンプルフロー
サンプルとして下図のようなFlowを作成しました。以下３パターンで実際に動かしてみます
<dl>
  <dt>①Assignment Groupが承認を行う</dt>
  <dt>②Assignment Groupが承認拒否する</dt>
  <dt>③Descriptionに「skip」と入力する</dt>
</dl>
<img width="950" alt="wf-pic9.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2707437/570477bf-c35d-484b-fb85-209d3cce015b.png">

##### サンプルフローの挙動①　Assignment Groupが承認を行う
ワークフロー対象テーブルのフォームからAssignment groupにTest Groupを指定し、Submit。（使用テーブルはTaskテーブルを拡張した試験用テーブルです）
<img width="950" alt="wf-pic10.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2707437/4cb5084b-5ac4-02eb-7c6e-f98983873fa5.png">

尚、Test Groupには以下4名を所属させています。
<img width="500" alt="wf-pic11.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2707437/63496998-fdd6-b74a-cd69-41e07715a4ae.png">

Group approvalsにTest Groupが入り…
<img width="950" alt="wf-pic12.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2707437/b1e5c83f-57b0-5f06-bc68-4a76d05bbffc.png">

ApproversにはTest Group所属の4名が入ります。
<img width="500" alt="wf-pic13.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2707437/a64a5c87-041e-f4e5-ae5a-28f9a4b30f0b.png">

自身（System Administrator）宛の承認レコードを選び、Approveしてみます
<img width="950" alt="wf-pic14.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2707437/1310d3e8-e211-7adb-6f49-6f595270ee67.png">

サンプルフロー全体図①からのフローが動き、親レコードのApprovalがApproved、StateがClosed Completeとなりました。
<img width="950" alt="wf-pic15.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2707437/518008c4-a451-65cb-e90a-8971869c98c1.png">

##### サンプルフローの挙動②　Assignment Groupが承認拒否する
今度は、先程ApproveしたところでRejectしてみます
<img width="950" alt="wf-pic16.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2707437/f40875e5-146a-4d57-8c7a-f6970ce2167a.png">

サンプルフロー全体図②からのフローが動き、親レコードのApprovalがRejected、StateがClosed Incompleteとなりました。
<img width="950" alt="wf-pic17.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2707437/e110d0db-222c-dca8-c824-ba8b53d83083.png">

##### サンプルフローの挙動③　Descriptionに「skip」と入力する
最後に承認データ作成後、承認行為を行う前にDescriptionに「skip」と入力してみます。
<img width="950" alt="wf-pic18.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2707437/3cf60573-99f2-18d4-08f7-89555c671b7d.png">

サンプルフロー全体図③からのフローが動き、承認レコードのApprovalがCancelledとなりました。
<img width="500" alt="wf-pic19.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2707437/dd239ae5-655f-9592-4ccb-843c426a18be.png">

# 参考リンク
[公式Document](https://docs.servicenow.com/ja-JP/bundle/sandiego-servicenow-platform/page/administer/workflow-activities/concept/c_ApprovalAndRollbackActivities.html)

弊社ブログへも[同様の記事を投稿](https://alpcom.co.jp/blog/20220801/?utm_source=Qiita&utm_medium=post&utm_campaign=ysi&utm_id=20220801)しております。