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

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

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

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

  • タスクを要求するユーザー (タスク要求者)。
  • タスクを割り当てるユーザー (タスク アサイナー)。
  • タスクに割り当てられるユーザー (タスク割当先)。
  • タスクに貢献するユーザー (タスク貢献者)。
ユーザー 詳細
要求作成者 インターフェース (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 にあるタスク参照を示しています。