承認タスクにユーザーをルーティングする

適切なユーザーが承認タスクを実行および承認し、それに関与するには、Process Composer によって認識されるラベルを使用することが重要です。

[Process Composer] > [承認タスク] で、ユーザーの構成は、複数ユーザーによるコラボレーションの実行中にタスクが割り当てられたユーザー、タスクが要求されたユーザー、およびタスクの貢献者として認識されます。

画像は、依頼者がプロセス実行者であり、割当先が承認者であることを示しています。

次の情報の表は、ロールやチームに承認をルーティングする際の構成、および意思決定の支援に使用できます。[ユーザー] 列には、プロセス構成で認識されたラベルが表示されます。[詳細] 列には、その構成のパラメーターが記述されます。


ユーザー	詳細
要求作成者	インターフェース (AARI Web または Automation Co-Pilot) を使用して要求が作成されるときの要求を作成したユーザー。要求作成者は、割り当てられたグループの一員である必要があります。要求が他の方法 (API、要求作成コマンド、CoE 承認事例など) で作成された場合要求作成者は、割り当てられたグループの一員である必要はなく、実行権限のみが必要です。
要求割り当てグループ	要求が作成されたロールまたはチーム。 `= createdByTeam` 例: プロセス (POC) の要求 POC-2 がチーム 202 で作成される。チーム 202 は要求割り当てグループ。このグループは自分のワークスペースに作成された要求への読み取りアクセスを持つ
タスクアサイナー	タスク (受信済み) に対応する必要があるロールやチーム。例: 要求のフォームタスクがロール 301 に割り当てられる。タスクアサイナーはロール 301。ロール 301 のユーザーは、[割り当て] タブでタスクを確認できる。
タスク要求者	タスクへの対応 (送信済み) を要求するロール、チーム、またはユーザー (要求作成者)。例: 要求のフォームタスクがチーム 403 から要求される。チーム 403 はタスク要求者。チーム 403 のユーザーは、[要求済み] タブでタスクを確認できる。
貢献者	タスクに貢献した (または貢献している) ユーザー。フォームとドキュメントの検証タスク (貢献者は送信前に入力) ステータスが Pending のとき、貢献者はタスクに割り当てられているか、タスクにロックされているユーザー。 `=assigneeID` または `lockedBy` Completed の場合、貢献者はタスクを送信したユーザー。 `=submittedBy` 承認タスク (貢献者は送信後に入力) ステータスが Waiting Approval (0/2) の場合、投稿者は空。ステータスが Waiting Approval (1/2) の場合、貢献者はタスクを承認したユーザーの userID。ステータスが Approved の場合、貢献者は要求を承認したすべてのユーザーの配列。 `=approvedBy` ステータスが Declined の場合、貢献者は要求を拒否したユーザー。 `=declinedBy`

承認タスクの可視性およびアクション

タスクシーケンス:

レスポンダーグループに属しているユーザーは、シーケンス全体でのタスクの進行状況を確認できます。
現在の承認タスク以外のタスクは、レスポンダーグループには表示されません。

タスクに対して可能なアクション:

コメント履歴

承認または拒否コメントの履歴を表示する
承認
- タスクを [承認] ステータスで送信する
- 承認送信時にコメントを追加する
拒否
- タスクを [拒否] ステータスで送信する
- 拒否通知送信時にコメントを追加する

ユーザーが特定のタスクを誰かに通知したい場合、タスク参照 ID をアクティブなタスクの URL で見つけることができます。

画像は URL にあるタスク参照を示しています。

Automation 360

承認タスクにユーザーをルーティングする