続・その承認ワークフロー、Power Automateにしませんか？
今年の年明けに以下の記事を投稿いたしました。
私が書いた技術系の記事の中では、元々そこそこアクセスを集めていたのですが、おそらくここ最近の情勢（コロナ禍、アフターコロナ・ウィズコロナを見据える必要がある）もあり、アクセス数が増えています。
今回は、Power Automateで作成した承認ワークフローをもう少し使いやすくカスタマイズしてみようと思います。
ペーパーレス、脱ハンコ文化に向けて動いている企業も多いかと思います。この機会に社内決済だけでも電子化してみてはいかがでしょうか。
承認ワークフローをカスタマイズする
現状の振り返りと目指す姿
年明けに作成した承認ワークフローにつきまして、フローチャートでざっくり振り返りますと、以下のような感じに。
SharePointで申請リストを作成し、Power Automateにてテンプレートを元にしてフローを組み立てただけでしたね。
詳細な作成方法については、年明けの記事をご覧いただきたく。
さて、当フローの問題ですが…承認されたときは良いのですが、拒否された場合には、指摘の点を直して、また新規で申請しないといけなくなります。
億劫極まりないので、再申請をできるようにします。フローチャートで表すと、以下のような感じに。
SharePoint側の修正
まずSharePoint側の修正です。
ステータス列の編集をします。
「拒否」を「差戻し」に変更。「再申請」を追加してみました。最後に[保存]をクリックするのをお忘れなく。
ついでに、書式設定もメンテナンスしておきましょう。
配色はお好みで。ここも最後に[保存]をクリックするのをお忘れなく。
Power Automate側の修正
序盤はひとまずそのままです。（SharePointのアイコンが変わってますね）
SharePointリストにアイテムが追加されたら、承認者に承認依頼が飛びます。
後半部も大きくは変わりません。
「拒否」のところを「差戻し」に変えます。ここでも[保存」をお忘れなく。
あとは、申請者が差戻しに対して内容修正して再申請したときの動きを実装するだけですね。
承認者への承認依頼メール送信（Start an approval）の前が、『SharePointリストのステータスが「再申請」になったら』というトリガーになるだけですね。
上手いこと並列のトリガーにできれば良いのですが、今回は横着して別フローにします。テンプレートから作成する場合は、おそらく以下テンプレートがふさわしいです。
『SharePointリストのステータスが「再申請」になったら』は、色々書き方あるかと思いますが、ざっくり以下のような感じになるかと。
SharePoint上の変更があった行について、ステータスが「再申請」の場合は、承認開始しましょうという流れになっています。
[ID]は「When an existing item is modified」と「複数の項目の取得」双方のIDが正しいことを確認するような指定に。[ステータスValue]は「When an existing item is modified」から取りましょう。
単純に『ある行のステータスが「再申請」になった』という条件だけだと、多分SharePointリストに存在する全行分メールが飛びます。事故です。
「はいの場合」の内容は、年明けに作成したものの「Start an approval」以降と全く同じです。
各ステップは以下のようにクリップボードを介してコピー・ペーストできますので、改めてアクションを追加していくよりもそのほうが捗ると思います。
動作確認
実際にテストしてみます。
まずは適当に新規申請。わざと添付ファイル忘れてみます。
承認者側で、コメントを書いて、拒否。
あっ…タイムゾーン合わせるの忘れてた…。気が向いたときにタイムゾーンの変更方法については追記しようと思いますので、ひとまずご容赦ください。
リスト上では、しっかり差戻しになっていますね。
申請者側にも差戻しになった旨、メールが届きます。
指摘の通り、添付ファイルを追加し、ステータスを「再申請」にします。（適当なファイルがなかったため年賀状になってますが目をつぶってください）
メールの件名・内容としては、新規申請と区別をつけるため、再申請であることを明記した件名・内容にしたほうがいいかもしれませんね。
とりあえず承認者でリンクに飛んでみます。
再申請になっていますね。添付ファイルも付いています。
ちなみに、リスト上もちゃんとステータス再申請になってます。
今回は内容良さそうなので、承認。
申請者には、承認された旨のメールが届きます。
動きは良さそうですね！
まとめ
今回は、Power Automateで作成した承認ワークフローをカスタマイズしてみました。
文面が英語だったりタイムゾーンがそのままだったりしますが、ご利用の環境に合わせて適宜変更いただければと思います。
私の方でも時間があるときにタイムゾーンの変更あたりは追記しようと思います。
その他ご不明な点等ございましたら、お気軽にコメントにてお知らせください。
それでは、また次回！
平成生まれのアラサー文系ぽんこつシステムエンジニア。
エンジニアらしく技術系の記事を書いたり、全く関係ない記事を書いたり、まったりやっていきたいです。
AI（人工知能）、デジタルマーケティング、DX、Office365活用、ガジェットなどに興味があります。
コメント
①share pointでリストにアイテムが追加されたとき と share pointリストのアイテムが変更されたとき で二つフローを作成すると、新規で作った際に二つの承認フローが出来上がってしまいます。変更時のみフローが発生するようにしたのですが、なりません。どうしてでしょうか？
➁[ID]は「When an existing item is modified」と「複数の項目の取得」双方のIDが正しいことを確認するような指定に。[ステータスValue]は「When an existing item is modified」から取りましょう。
の部分ですが、そのように設定してもメールが大量に送られてきてしまいます。なぜでしょうか？
コメントありがとうございます。
①②ともにIDの指定が上手くできていないような気がいたします。
設定内容について、画像付きで後ほどメールさせていただきますので、ご確認ください。
以前、質問してご回答いただきその後何度かトライし、問題は解決しました。
ですが、また別の問題が出てきてしまいました。
項目の更新をすると警告で「無限トリガーループを引き起こす可能性があります」と出てしまいます。そのため、フローを実行すると承認依頼がリストにある分だけ飛んできてしまいます。
解決策があれば教えていただたきたいです。
コメントありがとうございます。
リストの件数分メールが飛んでしまうということは、更新のあったレコードを上手く判定できていない可能性が高いですね。
また後ほどメールさせていただきますので、ご確認ください。
記事ありがとうございます。とてもわかりやすかったです。
1つ質問なのですが、この記事での差戻しってワークフローを一回終了させて新しいワークフローを開始するっていうやり方で実現しているんですよね？
ワークフローを終了させずに前の人にワークフローを戻すっていうのは難しいでしょうか？
コメントありがとうございます。
説明不足な点があったかもしれませんが、差戻し⇒新規で申請…という流れになっているのは、本記事の前の記事（https://ponkotsu-se.com/power-automate-workflow/）です。
本記事は、そのペインポイントを解消するために書きましたので、新規で申請し直さなくても、同じレコードで再申請ができるようになっています。
記事内では申請者と承認者しかいない想定なので、”前の人”が必然的に申請者になり、”戻す”動きはApprovalsの＜拒否＞で実現しています（記事内に記載の通り、申請者へ差し戻された旨のメールが飛び、ステータスは「差戻し」に）。
こちらこそ回答ありがとうございます。
何度もすみません。
これはFlowが２つありStart an approvalも2回ありますよね。
だから承認ワークフロー自体が２つになるなと思いました。一方は拒否(差戻し)された時点で自動的に終了になるのですかね？それなら確かに２つになっても問題ないですね。
インラインにて失礼いたします。
＞これはFlowが２つありStart an approvalも2回ありますよね。
＞だから承認ワークフロー自体が２つになるなと思いました。
⇒ おっしゃる通りです。
新規にレコード追加されたときに動くものと、
レコード内容に変更があったときに動くものです。
＞一方は拒否(差戻し)された時点で自動的に終了になるのですかね？
⇒ 両方とも、承認か拒否をされた時点で一度フローとしては終了になります。
承認フローが始まるトリガーとして、レコード追加 or ステータスが”再申請”になるという2通りを用意している構造になっております。
ありがとうございます！よくわかりました。
私は承認者が複数いる(承認順序が決まっている)承認ワークフローを作成したいと思っています。
承認順序が順不同のフローでしたらテンプレートがあったのですが、順番が決まっている場合のフローについてお時間ありましたらまた記事にして頂きたいです。宜しくお願い致します。
なるほど。確かに実務では承認者が複数いるパターンのほうがスタンダードですよね。
時間があるときに記事にしてみたいと思いますが、取り急ぎの実装イメージとしては以下のような感じになると思います。
・ステータスを分け（第1承認、第2承認、最終承認…など）、それぞれのトリガーで、各承認者へメール通知。
（ステータスが第1承認になったら課長、第2承認になったら部長…など）
・各承認者のメールアドレスは、ジョブ内に直接記載 or SharePointリストに項目として持つ。
尚、承認の返事がデフォルトでは”承認”か”拒否”しかないため、メール上で承認行為をさせるよりも、SharePointリストのリンクをメールに掲載⇒誘導しステータスを更新させるほうが実装は楽かもしれませんね。
誰でも最終承認にできてしまうという怖さは残りますが、更新者／更新時間は残るので一応抑止力にはなるかと。
現在社内の申請ワークフローをPowerAutomateを活用し構築しているのですが、
最大で5段階承認になる申請があります。
こちら複数段階の承認ワークフローを作成する場合、
ステータス変更（再申請）をトリガーとするフローは承認段階分作成する必要がありますでしょうか？
3段階承認の場合（例：上長→課長→部長）に作成するフロー
①トリガー：項目が作成された時
②トリガー：ステータスが変更された時（再申請：上長）
③トリガー：ステータスが変更された時（再申請：課長）
④トリガー：ステータスが変更された時（再申請：部長）
項目が作成された時、ステータスが変更された時、各フローの全体図などがあると非常に助かります。
是非参考にさせていただきたいです。
コメントありがとうございます。
直前にいただいたコメントへの回答が、ご参考になるかと思いますので再掲いたします。
分岐は承認段階分できる形になります。
————————————————————–
取り急ぎの実装イメージとしては以下のような感じになると思います。
・ステータスを分け（第1承認、第2承認、最終承認…など）、それぞれのトリガーで、各承認者へメール通知。
（ステータスが第1承認になったら課長、第2承認になったら部長…など）
・各承認者のメールアドレスは、ジョブ内に直接記載 or SharePointリストに項目として持つ。
尚、承認の返事がデフォルトでは”承認”か”拒否”しかないため、メール上で承認行為をさせるよりも、SharePointリストのリンクをメールに掲載⇒誘導しステータスを更新させるほうが実装は楽かもしれませんね。
誰でも最終承認にできてしまうという怖さは残りますが、更新者／更新時間は残るので一応抑止力にはなるかと。
————————————————————–
また、御社は業務・システム改革支援のサービスも取り扱われているようなので釈迦に説法かとは思いますが、PowerAutomateではかゆいところに手が届かない部分もございますので、複雑なことをしっかりと実装されたい場合には、パッケージソフト等の利用も検討された方が良いかもしれません。
ご回答ありがとうございます。
あれから色々やってみたのですが、上手く構築ができずでして相談させてください。
現状、「承認」された場合のフローは問題なく進められるのですが、
「拒否」後の項目修正→再申請→再承認の形が表現できず苦戦しております。
拒否された場合の理想の流れとしては下記のとおりで、
①～③までは動作確認済み、④の表現ができない状況です。
①承認ステータスは「差し戻し」に変更
②差し戻し通知が申請者に飛ぶ（承認アプリで通知）
③申請者が内容修正し、承認ステータスを「再申請」に変更
④ステータスが「再申請」に修正されたことをトリガーに、承認者へ再度承認依頼
→ここでの通知はTeamsを活用したいと考えています
ご丁寧にご説明頂いているのですが、私の理解不足で申し訳ございません。
フローの全体像を実際の画像付きでレビューなどいただけると助かります。
画像付きでレビューも不可能ではありませんが、
課題は明確だと思いますので、テキストベースにてご回答いたします。
ステータスが再申請になった際のフローの設計については、
[Power Automate側の修正]の中で記載の通りです。
再申請のフローは、別フローにしたほうが構造が分かりやすくなって良いかと思います。
上手く行かない場合は、更新のあったレコードを上手く判定できていない場合が多いです。
同名の項目も多いため、パラメーターを正しくセットできているか、再度ご確認いただいたほうが良いかもしれません。
また、通知にTeamsを使う場合は、「メッセージを投稿する（V3）（プレビュー）」というアクションを選択していただければ実装可能かと思います。