maestro
latest
false
Maestro ユーザー ガイド
- はじめに
- スタート アップ ガイド
- Maestro の BPMN を使用した構築
- Maestro Case を使用した構築
- Maestro Case について
- Maestro BPMN と Maestro Case の比較: ケース管理を使用すべき状況
- Maestro Case のライフサイクル: イベント トリガーからアプリのエクスペリエンスまで
- Maestro Case を使用して最初のケースを構築する
- コーディング エージェントを使用して Maestro Case を構築する (プレビュー)
- ケース キーを定義する (システムと外部)
- タスクの I/O と書き戻しの契約を確立する
- 終了ルールと早期終了
- プライマリ ステージとセカンダリ ステージをモデリングする
- Data Fabric からケースをトリガーする
- ステージレベルのペルソナと権限を実装する
- SLA と自動エスカレーション ルールを設定する
- 再作業によるループ (再エントリ) を設定する
- Case Manager エージェントを設定およびテストする (プレビュー)
- ケース マネージャーの入力および出力コントラクト
- Maestro Case コンポーネント ディクショナリ
- Maestro Flow を使用した構築
- Maestro Automate
- Integrations
- オペレーティング
- 監視
- 最適化中
- 参考情報
重要 :
このコンテンツの一部は機械翻訳によって処理されており、完全な翻訳を保証するものではありません。
新しいコンテンツの翻訳は、およそ 1 ~ 2 週間で公開されます。
レビュー ステップでワークフローを一時停止し、指定されたユーザーに承認タスクを送信し、その回答に基づいて続行します。
構築する内容: レビュー ステップで一時停止し、指定されたユーザーに承認タスクを送信し、そのユーザーが回答、承認、または却下されたら、正しいパスを続行するプロセス。このパターンは、続行する前に人間による承認が必要なプロセスの構成要素です。
このガイドでは、 クイック フォーム タスクの種類を使用します。承認フォームは「人間」ノード上で直接作成します。
必要なもの
- Maestro Flow へのアクセス権を持つ UiPath Automation Cloud アカウント。
使用されるノード
手順
1. 事前承認手順を構築する
まず、承認ポイントの前に実行されるノードを設定します。新しいフローを作成し、承認者が確認する必要があるデータをフェッチまたは受信するノードを追加してから、それを読み取り可能な形式に変換します。
2. 人間のノードを追加する
承認タスクを作成し、プロセスを一時停止するノードを追加します。
- [UiPath のノード] セクションから [人間の] ノードをキャンバスにドラッグします。
- 最後の事前承認ノードに接続します。
- プロパティ パネルで、タスクを設定します。
- 種別: クイック フォームに設定したままにします。
- タスクの配信: タスクが配信される、管理者が設定したチャンネル ( Action Center や Slack など) を確認します。
- 割り当て条件: 承認者を 1 人のユーザー、変数ベースのカスタム割り当て、またはラウンド ロビンやワークロード分散などのグループ割り当て戦略として設定します。
- スキーマ: フォームを定義します。承認者が確認する読み取り専用のコンテキスト用の 入力 フィールド (請求金額、依頼者名、サポート ドキュメントへのリンクなど) を追加し、各フィールドはプロセスの値 (例:
$vars.manualTrigger1.output["amount"]) にバインドされます。このシナリオでは、[ 承認] と [却下] の 2 つの結果を追加します。 - 優先度: 時間的制約のあるタスクの場合は 、高 に設定します。
3. 承認者の応答で分岐する
人間のノードには、定義した結果ごとに 1 つの出力ハンドルがあるため、各結果を直接ルーティングできます。
- [結果の 承認 ] ハンドルをプロセスの継続 (システムの書き込みや通知など) に接続します。
- [ 却下 ] 結果のハンドルを [強制終了 ] ノードに接続して、そのパスを正常に終了します。
4. テストとデバッグ
このフローをテストするために実際の承認者は必要ありません。次のいずれかのアプローチを選択します。
- モックせずにデバッグで実行する: フローをデバッグし、それが [人間] ノードに到達するようにします。タスクはキャンバス内でインラインで開くため、デバッガーを離れることなくタスクを完了し、実際のタスク エクスペリエンスを使用して承認分岐と却下分岐の両方を検証できます。
- モック出力を使用: タスクを完了するのではなく、応答をシミュレートします。
- [人間] ノードを選択し、プロパティ パネルで [モック出力 ] を開きます。
- モックのトグルを有効化します。
- [
status] を [Approve] に設定します (または、却下の分岐をテストする場合は [Reject]) に設定します。 - フローをデバッグし、正しい分岐が実行されることを確認します。
- パブリッシュする前にモックを削除します。
結果
プロセスは「人間」ノードで一時停止し、指定されたユーザーに承認フォームを送信し、指定されたユーザーが応答した後は、実行を正しいパスにルーティングします。承認されたパスによってオートメーションが続行されます。拒否されたパスは正常に終了します。
このフローを拡張する
- 承認者に通知する: [人間] ノードの前に、タスクが待機中であることを承認者に伝える通知ステップ (メールまたは Slack) を追加します。
- 却下時にエスカレーションする: 却下パスでは、直ちに終了するのではなく、 自律型エージェント を呼び出すか、2 番目の承認者にルーティングします。
- 承認者のメモを収集する: スキーマに 出力 フィールド (コメントなど) を追加し、ノードの後に
$vars.approval.output.comment読みます。