全員の承認を待って処理する

準備：テスト用のインスタントクラウドフローを作り、「手動でフローをトリガーする」を選びます。担当者A・Bは説明用の呼び名です。実際に試すときは、自分とテスト参加に同意した別の担当者など、異なる2人の組織アカウントを用意します。同じアドレスを2回書いても、2人の回答待ちを確認する練習にはなりません。

承認コネクタの「承認の開始と待機」（Start and wait for an approval）を追加し、種類を「承認/拒否 - 全員の承認が必要」にします。「最初に応答」や「カスタム応答 - すべての応答を待機」ではありません。割り当て先へ確認済みの2人のメールアドレスを半角セミコロン（;）区切りで入れます。タイトルは「練習01：資料の公開確認」、詳細は「テスト用です。実際の公開や購入は行いません。」にします。

まず結果だけ確認：条件をまだ作らず、承認の直後のデータ操作「作成」に、この承認の「結果（Outcome）」の動的コンテンツを選びます。実行条件は承認が「成功しました」の場合だけのままにします。保存して手動実行すると、ここから実際に2人へ承認依頼が作られます。個々の回答の一覧（Responses）と全体の結果を取り違えないよう、実行履歴で値を確認します。

確認A：練習01ではAだけが承認し、Bはまだ回答しません。承認アクションが待機中で、直後の作成がまだ動かないことを確認。その後Bも承認し、作成の出力がApproveになるか確認します。これは「1人承認で待機」から「全員承認で完了」への確認で、タイムアウトのテストではありません。

確認B：タイトルを「練習02：拒否の確認」に変えて別の手動実行を開始します。Aが拒否し、Bは回答しないまま、作成の出力がRejectになるか確認します。担当者の入力順は承認の順番を指定しません。図は同じ1件の依頼が3つの結果を同時に取る意味ではなく、回答の状態ごとの比較です。

分岐版にする：出力を確認できたら、確認用の作成を条件に置き換えます。左辺は同じ承認の全体の「結果（Outcome）」、比較は「等しい」、右辺は通常テキストApprove。はい側の作成には「全員承認」を入れます。いいえ側にもう1つ条件を置き、同じOutcomeがRejectと等しければ作成に「却下」、それ以外なら「結果を要確認」と入れます。条件の実行条件は承認が成功した場合だけです。配列や連結された回答など想定と異なる出力なら、そのまま却下扱いせず、承認の種類・参照元・出力形式を見直します。

最後の確認：新しいテスト依頼で全員承認と1人拒否を再確認し、実行履歴の該当する作成だけが動くか調べます。未回答で練習を終えず、確認Aのように回答して依頼を完了させます。依頼が届かないときは割り当て先、環境、承認アクションの状態を確認し、同じ依頼を何度も作らないでください。失敗・タイムアウト時はこの成功後の条件へ進まないため、関連するエラー処理の記事を参考に別の処理を設計します。