クイック フォーム

ワークフローを一時停止し、ノード上に構築したフォームを人間に確認、承認、または入力してもらってから、回答を続行します。

クイック フォーム はワークフローを一時停止し、タスク (ノード上に直接構築するフォーム) を人間に割り当てます。人間が質問を確認して入力し、承認や却下などの結果を選択すると、ワークフローはその結果のパスに従って続行されます。これは、[ノードを追加] パネルの [人間] カテゴリにあります。

承認や簡単なデータ収集には、クイック フォームを使用します。より充実したインターフェイスが必要な場合、ワークフロー間でインターフェイスを再利用する必要がある場合、またはワークフローにまだ伝送されていないデータを表示する必要がある場合は、代わりに アクション アプリ を使用してください。ワークフローに人間による承認を追加する クイック フォームをステップ バイ ステップで説明します。

クイック フォームを使用すべき状況と判断を下す場合

クイック フォームは、ワークフローを続行する前に人間が情報を確認して回答する必要がある場合に使用します。[ 判断 ] は、人間を介さずに既存のデータから分岐を自動的に解決できる場合に使用します。

構成

フィールド	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 にはコネクションが必要です。アクショナブルな通知では 、コネクタの設定について説明します。

出力

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

出力

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

ステータス

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

結果に対する分岐

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

Quick Form
  ├─ 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
• クイック フォーム タスク