人間

人間によるノード: プロセスを一時停止し、人間によるレビュー、承認、または入力のためにタスクを割り当てます。

ヒューマン ノードは、プロセスを一時停止してユーザーにタスクを割り当て、そのユーザーが完了するとプロセスを再開します。プロセスを続行する前に、人間による確認、承認、または入力が必要な場合に使用します。

人間と判断を使用する状況

[ 人間] ノードは、プロセスを続行する前にユーザーが情報を確認して対応する必要がある場合に使用します。判断 ノードは 、人間の関与なしに既存のデータから分岐を自動的に解決できる場合に使用します。

人間ノードは、担当者が選択した結果に対して、専用の出力ハンドルを介してルーティングします。分岐が個人の選択ではなく既存のデータに基づいている場合に、判断に到達します。

人間のノードの種類

人間に提示されるタスクは、 クイック フォーム と アクション アプリの 2 つのメカニズムで作成できます。

クイック フォーム

軽量フォームをノード上で直接構築およびデバッグします。担当者が表示するフィールド、担当者が提供する必要のある入力、担当者が選択できる結果を定義します。これは既定値であり、承認や単純なデータ収集に最適です。

アクション アプリ

アクション アプリは、人間に割り当てられたタスクに対して、完全にカスタマイズされた、より豊富なインターフェイスを提供します。UiPath App Studio、または Studio Web で視覚的に構築することも、コード化されたアクション アプリ (カスタムの React または Angular アプリケーション) として構築することもできます。[ アクション アプリ] でコード化されたアプリが選択され、その入力が設定時にマッピングされます。「 コード化されたアクション Apps について」をご覧ください。

	クイック フォーム	アクション アプリ
UI の定義	プロセスでバージョン管理されているノード	個別のアプリ。Orchestrator にデプロイされます。
プロセス間で再利用	はい、JSON をコピーして貼り付けます	はい
コスト	ユニットを追加せず、Apps への依存も不要	アプリのデプロイが必要
レイアウト	複数列、複数幅のレイアウトが許可されます。 フィールド動作	フルコントロール
レンダリング時のデータ	バインドされたプロセス変数/式のみ	SDK: アセット、バケット、コネクション、Data Fabric、トリガー プロセス
テスト	キャンバスからのインライン デバッグ	構築→デプロイ→実行
必要なスキルの構築	なし	App Studio、コード化されたAppsの場合は React/Angular

ヒント:

クイック フォームから始めます。同じインターフェイスを複数のプロセスで再利用する必要がある場合、プロセスがまだ伝送していないデータを表示する必要がある場合、フォームでは表現できない UI を構築する必要がある場合は、アクション アプリに移動します。

Building the Apps itself is covered in the Action Apps documentation.ここから、このページでは クイック フォーム タスクの種類について説明します。実践的なチュートリアルについては、「 ワークフローに人間による承認を追加する」をご覧ください。

構成

フィールド	Required	既定 (Default)	説明
割り当て条件	はい	単一のユーザー	人間ノードがタスクを取得するユーザーを選択する方法を制御します。[シングル ユーザー]、[すべてのユーザー]、[ラウンド ロビン]、[ワークロード]、[カスタム] から選択します。
スキーマ	はい	結果の送信	フォームの構造。担当者が表示または入力するフィールドや、担当者が選択できる結果が含まれます。完全な構造については、「 スキーマ 」をご覧ください。
配信チャネル	—	テナント レベルで設定する	ノードでの読み取り専用 — 利用可能なチャネルはテナント レベルの設定から継承され、[無効] チェックボックスとして表示されます。詳しくは「 配信チャネル 」をご覧ください。
タスク タイトル	いいえ	なし	タスク リスト内の担当者に表示されるタイトル。
優先度	いいえ	なし	Action Center に表示される優先度は、 低、 中、 高です。
ラベル	いいえ	なし	タスクを整理するためのコンマ区切りのラベル (例: finance,approval)。

割り当て条件

割り当て条件では、タスクを受け取るユーザーを制御します。条件を選択すると、一致する 2 番目のフィールドが変更されます。これは、シングル ユーザーの場合はユーザー ピッカー、グループベースの条件の場合はグループ ピッカーです。

基準	タスクを取得するユーザー	次の場合に使用します
単一のユーザー	名前付き人物 1 人。	この決定を所有する特定の個人 (指名承認者、1 人のレビュー担当者)
すべてのユーザー	グループのすべてのメンバーを一度に実行できます。最初に完了した人が全員のタスクを閉じます。	あなたは所有権よりもスピードを重視します。自由な人はそれを拾います
作業負荷	未実行のタスクが最も少ない 1 つのグループ メンバー	キューをチーム全体に均等に分散させる
ラウンド ロビン	グループ メンバーを順番にクリックして、メンバーシップ リストを循環します	各メンバーは、作業の速さに関係なく、各メンバーが平等に分け前を取りたいと考えています
カスタム	未実行のタスクが最も少ないメンバー。グループのフル メンバーシップからではなく、実行時に指定したユーザーのリストから選択されます。	実行ごとの資格の変更 — 不在の人、シフト外の人、または適切な役割や地域外の人をスキップします。

要件と制限事項

重要:

ワークロードとラウンド ロビンにはローカル グループが必要です。Active Directory グループは両方に対して拒否されます。担当者が Active Directory (AD) グループに属している場合は 、[シングル ユーザー ] または [すべてのユーザー ] を使用します。

デバッグでは、個人用ワークスペースからのグループ割り当ては機能しません。デバッグ実行: グループ メンバーがアクセスできない個人用ワークスペースにタスクを作成します。そのため、タスクは作成されますが未 割り当てのままになり、通知は送信されません。これは予期されたことであり、不具合ではありません。ソリューションを共有フォルダーにデプロイして、グループの割り当てを正しくテストします。単一ユーザーの割り当ては、デバッグでは正常に機能します。

表示される可能性のあるエラー:

Error	意味
NoUsersFoundInLocalGroup	選択したグループにメンバーがありません。
NoEligibleUsersFoundInGroup	すべてのメンバーが除外されたので、割り当てられる人が残っていません。

スキーマ

スキーマでは、担当者に表示する内容と、担当者がプロセスに返す内容を定義します。プロジェクトには、フィールドと結果の 2 つの部分があります。

フィールド

スキーマは JSON として直接編集することもできます。JSON スキーマの完全なリファレンスについては、「 クイック フォーム タスク 」をご覧ください。フォーム ビューでは、各フィールドに次の設定があります。

設定	機能
ラベル	担当者に表示される表示名です。
入力	検証と入力の表示方法を制御します。利用可能な種類は、[テキスト]、[数値]、[小数値]、[日付]、[日付と時刻]、[はい] または [いいえ]、[単一選択]、[複数選択]、[配列]、[ファイル] です。
バインド	フィールドに事前に入力される式 (例: $vars.requestAmt)。変数参照だけでなく、あらゆるワークフロー式を受け入れます。
編集可能	値の横にある南京錠。ロックされているとは、担当者が値を読み取ることはできるものの、変更できないことを意味します。
変数	フィールド名の横に (x) バッジとして表示されます。[出力] フィールドおよび [入力/出力] フィールドのラベルから自動派生され、値は に加えて名前付きプロセス変数としても公開 $vars.<nodeName>.output.<fieldId>。入力フィールドには存在しません。

フィールドの指示

フィールドは、タスクに出入りするデータを運びます。各フィールドには方向があります。

• 入力 フィールドは担当者の読み取り専用のコンテキストであり、プロセスの値 (例: $vars.start.output.employeeName) にバインドされます。
• 出力 フィールドは担当者によって入力され、プロセスに返されます。
• 入力/出力 フィールドは、その両方を行います。つまり、担当者にプロセスの値を出発点として表示し、担当者はその値を編集してからプロセスに戻すことができます。

フィールドの 方向 は個別の設定ではありません。これは 2 つのコントロールの結果です。フィールドが バインド されているかどうかによってフィールドが事前に入力された状態で到着するかどうかが決まり、 ロック解除 されているかどうかによって担当者がフィールドを変更できるかどうかが決まります。

バインド	南京錠	方向	割当先には以下が表示されます	編集可能で返品
Set	ロック済み 🔒	入力	バインドされた値です。	いいえ
Set	ロック解除 🔓	入力/出力	バインドされた値です。	はい
なし	ロック解除 🔓	出力	空のフィールド	はい
なし	ロック済み 🔒	無効	空のフィールド	いいえ

結果

結果は、担当者がタスクを完了するために使用するボタンです ( 例: 承認 、 却下)。既定のスキーマでは、[ 送信 ] の結果が 1 つになります。最初の結果がプライマリ アクションとしてマークされます。

各結果は、独自の出力ハンドルをノードに追加します。担当者が結果を選択すると、プロセスはその結果のハンドルから続行されるため、各結果を異なるパスにルーティングできます。「 結果の分岐」を参照してください。

配信チャネル

タスクは以下に配信されます。

• Action Center
• メール
• Slack
• Microsoft Teams

重要:

配信チャネルは、テナント レベルの [管理者設定] からのみ変更できます。ノードのチェックボックスは無効化され、現在のテナント設定が反映されます。

Slack と Microsoft Teams には、Integration Service のコネクションが必要です。コネクタの設定については、「 アクショナブルな通知 」をご覧ください。

出力

ノードの出力に $vars.<nodeName>.output でアクセスし、選択した結果に $vars.<nodeName>.statusでアクセスします。

出力

タスクの結果: 担当者が送信した値を保持するオブジェクトです。キーは出力フィールドで設定されます。$vars.<nodeName>.output.<fieldId>で 1 つのフィールドを読み込みます。このオブジェクトには、選択した結果に設定された Action プロパティも含まれます。

ステータス

担当者が選択した結果です (例: Approve)。この値で分岐してプロセスをルーティングします。

結果に対する分岐

定義した各結果により、出力ハンドルが [人間] ノードに追加されます。担当者がタスクを完了すると、担当者が選択した結果のハンドルからプロセスが続行されます。各結果ハンドルを、そのパスに対して実行するノードに接続します。結果を分割するために [判断] ノードは必要ありません。

Human
  ├─ Approve → continue processing
  └─ Reject  → notify the requester and terminate

送信済みフィールドを任意の下流ノードで読み取る $vars.<nodeName>.output.<fieldId>

// In a Script node on one of the outcome paths
return $vars.approval.output.comment;

選択した結果は、式で必要な場合は $vars.<nodeName>.status としても使用できます。

一般的な問題

担当者のタスクが表示されない

担当者が正しいか (ユーザーかグループか) であり、Action Center へのアクセス権を持っていることを確認します。

出力値がありません。

フィールドがスキーマで定義され、出力方向が定義されていることを確認します。

結果が間違ったパスにルーティングされる

各結果の出力ハンドルが目的のノードに接続されていることを確認します。スキーマで定義した各結果には、人間ノードで独自のハンドルがあります。

備考

注:

実際の担当者なしでテストするには、[ モック] 出力 を使用して status と output 応答をシミュレートします。手順については、「 ワークフローに人間による承認を追加する 」をご覧ください。

• 担当者がグループの場合、そのグループのメンバーは誰でもタスクを要求して完了できます。
• フォームよりも充実したインターフェイスを利用するには、クイック フォームではなくアクション アプリを使用してタスクをサポートします。

関連ページ

• ワークフローに人間による承認を追加する
• 判断
• Terminate
• クイック フォーム タスク