#手動処理

This feature is provided by the plugin «ワークフロー：手動処理ノード»

#概要

業務プロセスにおいて、意思決定を完全に自動化できない場合があります。そのような場合、「手動処理ノード」を使用することで、一部の意思決定を人間に委ねることができます。

手動処理ノードが実行されると、まずワークフロー全体の実行が一時停止し、担当ユーザーに「ToDoタスク」が生成されます。ユーザーがタスクを提出すると、選択されたステータスに基づいて、ワークフローを「続行」するか、「待機」を続けるか、または「終了」するかが決定されます。この機能は、承認プロセスなどのシナリオで非常に役立ちます。

#インストール

このプラグインは組み込み済みのため、インストールは不要です。

#ノードの作成

ワークフロー設定画面で、ワークフロー内のプラス（「+」）ボタンをクリックし、「手動処理」ノードを追加します。

#ノードの設定

#担当者

手動処理ノードでは、ToDoタスクの実行者としてユーザーを指定する必要があります。ToDoタスクのリストは、ページにブロックを追加する際に設定でき、各ノードのタスクポップアップの内容は、ノードのインターフェース設定で構成する必要があります。

ユーザーを直接選択するか、変数を使用してコンテキストからユーザーデータの主キーまたは外部キーを選択します。

#ユーザーインターフェースの設定

ToDoアイテムのインターフェース設定は、手動処理ノードの核となる部分です。「ユーザーインターフェースを設定」ボタンをクリックすると、独立した設定ポップアップが開きます。通常のページと同様に、WYSIWYG（見たまま編集）方式で設定できます。

#タブ

タブは、異なるコンテンツを区別するために使用できます。例えば、承認用のフォーム提出に1つのタブ、却下用のフォーム提出に別のタブ、または関連データの詳細表示などに利用でき、自由に設定可能です。

#ブロック

サポートされているブロックタイプは、主に「データブロック」と「フォームブロック」の2種類です。その他に、Markdownはヒント情報などの静的コンテンツに主に使用されます。

#データブロック

データブロックでは、トリガーデータまたは任意のノード処理結果を選択でき、ToDo担当者に関連するコンテキスト情報を提供するために使用されます。例えば、ワークフローがフォームイベントによってトリガーされる場合、トリガーデータの詳細ブロックを作成できます。これは通常のページの詳細設定と同様で、トリガーデータ内の任意のフィールドを選択してデータを表示できます。

ノードデータブロックも同様に、上流ノードからのデータ結果を詳細として表示できます。例えば、上流の計算ノードの結果を、担当者のToDoタスクのコンテキスト参照情報として利用できます。

#フォームブロック

ToDoインターフェースには、ワークフローを続行するかどうかの最終決定を処理するために、少なくとも1つのフォームブロックを設定する必要があります。フォームを設定しない場合、プロセスが中断された後に続行できなくなります。フォームブロックには以下の3つのタイプがあります。

• カスタムフォーム
• データ新規作成フォーム
• データ更新フォーム

データ新規作成フォームとデータ更新フォームでは、ベースとなるコレクションを選択する必要があります。ToDoユーザーがフォームを提出すると、フォーム内の値を使用して指定されたコレクションのデータが新規作成または更新されます。カスタムフォームでは、コレクションに紐付かない一時的なフォームを自由に定義でき、ToDoユーザーが提出したフィールド値は後続のノードで使用できます。

フォームの送信ボタンは、以下の3つのタイプに設定できます。

• 送信してワークフローを続行
• 送信してワークフローを終了
• フォーム値のみを一時保存

これら3つのボタンは、ワークフロー処理における3つのノードステータスを表します。提出後、ノードのステータスは「完了」、「却下」、または「待機中」のいずれかに変更されます。ワークフロー全体のその後の処理の流れを決定するためには、フォームで最初の2つのうち少なくとも1つを設定する必要があります。

「ワークフローを続行」ボタンでは、フォームフィールドへの値の割り当てを設定できます。

ポップアップを開くと、フォームの任意のフィールドに値を割り当てることができます。フォームが提出されると、この値がフィールドの最終値として使用されます。これは、データをレビューする際に特に役立ちます。フォーム内で複数の異なる「ワークフローを続行」ボタンを使用し、各ボタンでステータスのようなフィールドに異なる列挙値を設定することで、異なるデータ値を使用して後続のワークフロー実行を続行する効果を実現できます。

#ToDoブロック

手動処理を行うには、ToDoタスクを表示するためのToDoリストをページに追加する必要があります。これにより、関係者はこのリストを通じて手動処理ノードの具体的なタスク処理に進むことができます。

#ブロックの追加

ページ内のブロックから「ワークフローToDo」を選択し、ToDoリストブロックを追加できます。

ToDoリストブロックの例：

#ToDoの詳細

その後、関係者は対応するToDoタスクをクリックしてToDoポップアップを開き、手動処理を行うことができます。

#例

#記事のレビュー

一般ユーザーが投稿した記事は、管理者の承認を経て初めて「公開済み」ステータスに更新されるとします。もしワークフローが却下された場合、記事は「下書き」状態（非公開）のままになります。このプロセスは、手動処理ノードの更新フォームを使用して実装できます。

「記事の新規作成」によってトリガーされるワークフローを作成し、手動処理ノードを追加します。

手動処理ノードで担当者を管理者に設定します。インターフェース設定では、トリガーデータに基づくブロックを追加し、新規作成された記事の詳細を表示するようにします。

設定インターフェースで、データ更新フォームに基づくブロックを追加し、記事コレクションを選択します。これは管理者が承認するかどうかを決定するために使用され、承認後には後続の他の設定に基づいて対応する記事が更新されます。フォームを追加すると、デフォルトで「ワークフローを続行」ボタンが表示されます。これを「承認」とみなし、さらに「ワークフローを終了」ボタンを却下用として追加します。

ワークフローを続行する際、記事のステータスを更新する必要があります。これには2つの設定方法があります。1つは、記事のステータスフィールドをフォームに直接表示し、操作者が選択できるようにする方法です。この方法は、フィードバックの提供など、能動的なフォーム入力が必要な状況に適しています。

操作者の作業を簡素化するため、もう1つの方法は、「ワークフローを続行」ボタンでフォーム値の割り当てを設定することです。割り当てで「ステータス」フィールドを追加し、値を「公開済み」と設定すると、操作者がボタンをクリックした際に記事が「公開済み」ステータスに更新されることを意味します。

次に、フォームブロックの右上にある設定メニューから、更新するデータのフィルター条件を選択します。ここでは「記事」コレクションを選択し、フィルター条件を「ID と等しい トリガー変数 / トリガーデータ / ID」とします。

最後に、各ブロックのタイトル、関連するボタンのテキスト、およびフォームフィールドのヒントテキストを変更して、インターフェースをより使いやすくすることができます。

設定パネルを閉じ、「送信」ボタンをクリックしてノード設定を保存すると、ワークフローの設定は完了です。このワークフローを有効にすると、新しい記事が作成された際に自動的にトリガーされます。管理者はToDoタスクリストからこのワークフローの処理が必要であることを確認でき、クリックして表示するとToDoタスクの詳細を見ることができます。

管理者は記事の詳細に基づいて手動で判断し、その記事を公開できるかどうかを決定できます。公開できる場合は「承認」ボタンをクリックすると、記事は「公開済み」ステータスに更新されます。公開できない場合は「却下」ボタンをクリックすると、記事は「下書き」状態のままになります。

#休暇申請の承認

従業員が休暇を申請する場合、上司の承認を経て初めて有効となり、該当従業員の休暇データが差し引かれるとします。また、承認または却下にかかわらず、リクエストノードを通じてSMS APIを呼び出し、従業員に関連する通知SMSを送信します（「HTTPリクエスト」セクションを参照）。このシナリオは、手動処理ノードのカスタムフォームを使用して実装できます。

「休暇申請の新規作成」によってトリガーされるワークフローを作成し、手動処理ノードを追加します。これは以前の記事レビュープロセスと似ていますが、ここでは担当者が上司です。インターフェース設定では、トリガーデータに基づくブロックを追加して新規休暇申請の詳細を表示し、さらにカスタムフォームに基づくブロックを追加して上司が承認するかどうかを決定できるようにします。カスタムフォームには、承認ステータスを示すフィールドと却下理由のフィールドを追加します。

記事レビュープロセスとは異なり、上司の承認結果に基づいて後続のプロセスを続行する必要があるため、ここでは「ワークフローを続行」ボタンのみを提出用として設定し、「ワークフローを終了」ボタンは使用しません。

同時に、手動処理ノードの後には、条件判断ノードを使用して上司が休暇申請を承認したかどうかを判断できます。承認されたブランチでは、休暇を差し引くデータ処理を追加し、ブランチの終了後には、従業員にSMS通知を送信するためのリクエストノードを追加します。これにより、以下の完全なワークフローが完成します。

その条件判断ノードの条件設定は、「手動処理ノード / カスタムフォームデータ / 承認フィールドの値が『承認済み』であるか」となります。

リクエスト送信ノード内のデータでは、手動処理ノードの対応するフォーム変数を使用して、承認と却下のSMSコンテンツを区別することもできます。これでワークフロー全体の構成が完了です。ワークフローを有効にした後、従業員が休暇申請フォームを提出すると、上司はToDoタスクで承認処理を行うことができます。操作は基本的に記事レビュープロセスと同様です。