一次承認が通った後だけ二次承認を依頼する
SharePointの申請を担当者、責任者の順に承認します。一次で却下されたら二次へ進めず、二次の結果で最終状態を更新する直列の承認フローです。
画面上の名前は、表示言語やバージョンによって異なる場合があります。クラウドフローはトリガー（フローを開始する条件）から始まり、その後にアクションを実行します。値の受け渡しには、前のステップの出力を選ぶ「動的コンテンツ」を使います。式は［式］欄へ入力します。
実行前に確認
- 利用するサービスの契約・接続権限と組織のデータポリシーを確認します。標準コネクタでも、すべての契約で追加費用なしに使えるとは限りません。
- 承認はフロー実行の期限内に完了する必要があります。長期間の放置を想定した設計ではありません。タイムアウトや失敗は却下と同じではなく、この例では申請中のまま残るため、実行履歴の監視とエラー通知を別途設計してください。
- 1つの承認アクションに2人をまとめて指定する方式ではなく、2つの承認アクションを条件の中でつなぐ方式です。
- 承認を受け取れても元のSharePoint項目を閲覧できるとは限りません。承認者の閲覧権限を事前に確認します。再実行すると再度承認依頼が出るので注意してください。
1使うトリガーとアクション
- トリガー項目が作成されたときSharePoint：申請リスト
- アクション開始して承認を待機名前を一次承認に変更。担当者1名へ
- アクション条件一次承認の結果＝Approve
- アクション開始して承認を待機はい側だけ：二次承認。責任者1名へ
- アクション条件 → 項目の更新二次のApprove／Rejectで最終状態を保存。一次のいいえ側は一次却下を保存
図で見る処理のイメージ
概念図申請ID＝18、Title＝備品購入の例。分岐ごとに到達する結果が変わります。
申請作成
ID18／状態＝申請中
一次承認
Approveなら二次へ。Rejectなら一次却下で終了
二次承認
Approveなら承認済み。Rejectなら二次却下
同じ項目へ保存
ID18の状態を更新。別の項目を新規作成しない
両方がApproveのときだけID18が承認済みになります。一次却下では二次の依頼を作成しません。
架空の練習データによる説明です。実際のフローを実行して確認した結果ではありません。
設定と処理を説明する模式図です。実際の設定画面や実行結果のスクリーンショットではありません。
2実際の設定内容
入力する値・操作手順を確認する7ステップの設定と確認方法
- 1
準備：SharePointに申請用リストを作り、必須のTitle列（申請名）と、選択肢列「状態」を用意します。状態の選択肢は「申請中」「承認済み」「一次却下」「二次却下」、既定値は申請中です。承認者2名は事前に決め、まずはテスト用の申請・承認者で確認します。
- 2
SharePointの「項目が作成されたとき」にサイトとリストを設定します。「作成または変更されたとき」ではないため、この例の状態更新では再起動しません。
- 3
「開始して承認を待機」を追加して名前を一次承認に変更。承認の種類＝承認/拒否 - 最初に応答、タイトル＝トリガーのTitle、割り当て先＝担当者1名。詳細に申請IDを入れ、項目リンクにはトリガーの項目へのリンクを使います。
- 4
条件では一次承認の動的コンテンツ「結果（Outcome）」が Approve と等しいかを判定します。表示が日本語でも比較値は Approve です。はい側だけに同じ承認アクションを追加し、名前を二次承認、割り当て先を責任者1名にします。
- 5
二次承認の直後にもう1つ条件を置き、今度は二次承認の結果を Approve と比較します。はい側の「項目の更新」で状態＝承認済み、いいえ側で状態＝二次却下。両方ともサイト・リストは同じ、ID＝トリガーのID、Title＝トリガーのTitleを設定します。他の必須列がある場合も元の値を渡します。
- 6
最初の条件（一次承認）のいいえ側にも「項目の更新」を置き、同じIDとTitleを使って状態＝一次却下にします。二次承認はこの枝に置きません。
- 7
テストは「一次却下」「一次承認→二次却下」「両方承認」の3通り。リストの状態がそれぞれ一次却下・二次却下・承認済みになるかと、一次却下時に二次の依頼が出ないかを確認します。
- 対象環境
- クラウドフロー（Microsoft 365 組織アカウント）
- 更新日
- 2026年10月6日