Formsで承認フローを作れるかを調べている人が知りたいのは、作れるかどうかより、その形でいつまで足りるかです。フォームに入力してもらい、上司の承認を経て、結果を申請者に返すところまでは組めます。ただし、組んだあとに残る手作業があり、それが件数とともに増えます。この記事では、Formsと自動化の仕組みで承認フローを組む手順を押さえたうえで、その形で足りる範囲、つまずきやすい設定、そして足りなくなったときの足し方までを順に整理します。
Formsだけでは承認フローにならない理由
Microsoft Formsは、質問を並べて回答を集める道具です。集めた回答は表形式で書き出せますが、回答に対して「承認する」「差し戻す」という操作を行う機能はありません。承認フローを組むには、回答が届いたことをきっかけに動く別の仕組みが必要になります。
その役割を担うのがPower Automateです。Formsに新しい回答が届いたことをきっかけにして、承認を求める操作を挟み、結果によって処理を分けます。承認の操作そのものは、専用のアクションとして用意されています。
Power Automate を使用すると、SharePoint、Dynamics 365、Salesforce、職場または学校用 OneDrive、Zendesk、WordPress などの複数のサービスにわたるドキュメントやプロセスの承認を管理できます。 出典: learn.microsoft.com
承認フローを作るときに使うのは「承認 - 開始して承認を待機」というアクションです。このアクションを流れの中に置くと、指定した相手に承認の依頼が届き、返答があるまで流れが止まります。承認者は、メールの受信箱から直接返答することも、Power Automateの承認センターから返答することもできます。
この組み合わせで何ができるかを、実際に作った人の記録が端的に示しています。
簡単な申請、承認であればFormsとPowerAutomateでできました。 Formsを使用することでデザインを申請画面を用意する手間が減りさくっと作れました。 Formsにファイル添付をすることもできますし、承認者を選ぶこともできるかと思います。 また、承認の段階を複数にし、今回の例で言えば共済金の振込処理依頼、完了などもう少しに複雑にできる余地も考えられます。 勤怠システムが絡まない、いまだに紙、ファイルでの申請フローであれば今回の様なもので十分に置き換えられる可能性はあるなと今回作成してみて感じました。 出典: blog.est.co.jp
紙とファイルで回していた申請を置き換えられる、というのが妥当な評価です。逆に、勤怠のように別の仕組みが絡む申請や、社外の人が申請する場面では、そのままでは収まりません。どこまでが範囲なのかを先に押さえておくと、作り始めてから止まりません。
承認フローを組む手順
組む順番は決まっています。この順で進めると、途中で作り直しになりません。
第1に、Formsで申請の様式を作ります。入れる項目は、承認者が判断に使うものだけにします。ファイルの添付が必要なら、添付の設問を置きます。
第2に、自動化の側で新しい流れを作り、きっかけを設定します。Formsに新しい回答が届いたときに動く形にします。
第3に、回答の内容を取得する操作を足します。きっかけの段階では回答があったことしか分からないため、中身を読む操作が別に必要です。ここを忘れると、承認の依頼に何も表示されません。
第4に、申請者の情報を取得する操作を足します。誰が出したのかを承認の依頼に表示するために使います。
第5に、承認のアクションを置きます。承認者を指定し、依頼に表示する題名と詳細を組み立てます。詳細には、申請者の氏名と回答の中身を差し込みます。
第6に、承認の結果で処理を分けます。承認された場合と却下された場合で、別のメールを送る形にします。
第7に、結果を記録する操作を足します。承認の結果をリストか表に書き込みます。ここが無いと、あとから「どの申請が承認されたか」を追えません。
第8に、試して直します。この工程を省くと、運用開始後に設定の抜けが出ます。
第9に、承認者が不在のときの経路を決めます。固定の1人を指定したままでは、その人が休暇の間に申請が溜まります。複数人を指定して誰か1人の返答で進める形にするか、一定の日数が過ぎたら別の相手に依頼する形を組み込みます。
第10に、運用ルールを1枚の文書にまとめます。どの申請をどのフォームから出すか、承認の期限は何日か、却下されたときにどうするか、例外のときは誰に連絡するか。この4つを書いて申請者に配ると、問い合わせが大きく減ります。
各工程で必要な操作は公式の資料に手順として並んでいるため、そこを見ながら進めるのが確実です。作りながら覚えるより、先に完成形を読んでから手を付けたほうが早く終わります。
Formsの側で決めておく5つのこと
流れを組む前に、様式の側を固めておきます。あとから項目を変えると、流れの中で差し込んでいる値がずれて、承認の依頼が空欄になります。
第1に、項目を承認者が判断に使うものだけに絞ります。既存の紙の様式には、誰も見ていない欄が残っています。承認者に「この欄を判断に使っているか」を1つずつ確認すると、たいてい3割前後が落ちます。
第2に、必須の設定を入れます。未入力のまま送信できない作りにすると、記入漏れによる差し戻しがほぼなくなります。添付が必要な申請では、添付の設問も必須にします。
第3に、金額の欄を分けます。本体、税、付随する費用。1つの欄にまとめると、決裁の基準額の判定ができません。基準額で承認者を分ける設計にするなら、判定に使う数字が単独の欄に入っている必要があります。
第4に、選択式にできる欄を選択式に変えます。部署、費目、申請の区分。自由記入のままだと表記が揺れ、承認者を条件で振り分ける設定が働きません。選択式にしておけば、その値をそのまま分岐の条件に使えます。
第5に、項目の並び順を決めます。承認者が最初に見る情報を上に置きます。申請の区分、金額、理由の順に並べると、依頼の画面で上から読んで判断できます。
様式が固まったら、内容を1枚の紙に書き出してから流れを組みます。項目の名前と型を書いておくと、流れの中で差し込む値を間違えません。
つまずきやすい設定は5つある
実際に組んだ人がつまずく箇所は、繰り返し同じところに出ます。
1つ目は、回答の中身が承認の依頼に入っていないことです。きっかけの段階で取得できるのは回答の識別子だけなので、中身を読む操作を別に置く必要があります。これを忘れると、承認者は何を承認するのか分からないまま依頼を受けます。
2つ目は、申請者の氏名が入っていないことです。宛名や申請者名を表示するには、利用者の情報を取得する操作を挟みます。ここが空だと、承認者が誰の申請か分からず、問い合わせが発生します。
3つ目は、承認者の指定の仕方です。固定の1人にする形と、フォームの回答内容によって変える形があります。部署や金額で承認者が変わる運用なら、条件による分岐を入れます。固定にしたまま運用を始めると、その1人が不在のときに全部が止まります。
4つ目は、却下された場合の処理です。承認された場合だけを作って、却下の経路を作らないまま公開してしまう例があります。却下されたのに申請者へ何も届かず、申請者が待ち続けます。
5つ目は、実行の回数です。自動化の仕組みには、利用しているプランに応じた実行回数の考え方があります。上限や料金の条件は変わるため、いつ時点の条件かを確かめてから本番に載せてください。公開資料に記載が見当たらない点は、契約している窓口に確かめるのが確実です。
これらを見つける方法は1つしかありません。作った流れを、実際の使い方に近い状況で動かすことです。
こうした設定の必要性は、作成したフローの動作確認を注意深く行うことで気が付きます。動作確認は実際の利用シーンを想定し、それに近い状況で行いましょう。今回のような承認を含むフローの場合は、まわりの同僚などに声を掛けて、自分以外の数人に申請を行ってもらうようにします。そうすることで、フローの設定漏れや間違いに気付きやすくなります。 出典: dekiru.net
自分1人で通すと、権限の違いと通知の抜けに気づけません。申請する側の数人に実際に出してもらい、承認者にも返答してもらう工程を必ず挟んでください。
承認の結果を、どこに記録するか
承認の依頼と返答だけを作ると、記録がどこにも残りません。あとから「どの申請が承認されたか」を追えなくなるため、記録の置き場所を先に決めます。
もっとも簡単なのは、Formsの回答の一覧をそのまま台帳にする方法です。ただし、回答の一覧に承認の結果を書き込むことはできません。承認の結果は別の場所に記録することになります。
次に考えられるのは、SharePointのリストか表計算のファイルに1行ずつ書き込む方法です。回答の内容と承認の結果、承認した人、承認した日時を同じ行に並べます。この形なら、条件で絞って一覧にできます。
3つ目は、記録を残す先を業務の仕組みの側に置く方法です。採用なら応募者の管理、購買なら発注の台帳。承認の結果をそこへ渡し、以降の工程はその仕組みで追います。転記が発生しない代わりに、連携の設定が必要になります。
どの方法を選ぶ場合も、記録に含める項目は決まっています。申請の識別子、申請者、申請日時、金額や区分といった判断に使った値、承認の結果、承認した人、承認した日時。この7つが揃っていれば、後から追えます。
記録の場所を決めるときは、書き出せるかどうかも同時に確かめてください。表形式で書き出せない場所に記録を積むと、別の道具に移すときに過去分を置いていくことになります。
この形で足りるのは、どういう使い方か
乗り換える理由が無い場合を先に押さえておきます。次の条件が揃っているなら、Formsと自動化の組み合わせで十分に回ります。
第1に、申請する人が全員社内にいることです。組織のアカウントを持っているため、ログインが障害になりません。
第2に、承認が1段か2段で済むことです。段数が増えるほど、流れの設定が複雑になります。
第3に、申請の種類が少ないことです。種類ごとに流れを作る必要があるため、種類が増えると管理する流れの数が増えます。10種類を超えたあたりから、どの流れがどの申請に対応しているかが分からなくなります。
第4に、承認したあとに事務局の作業が続かないことです。承認して結果を返すだけで完了する申請なら、この形で足ります。
第5に、すでにMicrosoft 365を使っていることです。追加の契約をせずに始められる点が、この形のもっとも大きな利点です。
第6に、記録を後から追う必要が軽いことです。承認の結果を残す先を用意すれば追えますが、1件ごとのやり取りの履歴まで残す設計にすると、作る手間が増えます。
逆に、条件が崩れると別の形が必要になります。もっとも多いのが第1の条件です。社外の人が申請する場面では、組織のアカウントを持っていないため、フォームの公開範囲を広げる設定が必要になり、回答者の識別も別の手段が要ります。
第4の条件も崩れやすい部分です。承認のあとに書類を受け取る、進行の状況を追う、相手と何度もやり取りをする。こうした工程がある申請では、承認の流れだけでは足りません。
社外からの申し込みを受けるときに起きること
社外からの申し込みを、社内向けの仕組みで受けようとすると3つの問題が出ます。
1つ目は、ログインです。組織のアカウントを持たない相手にログインを求めると、そこで申し込みをやめる人が出ます。応募や問い合わせの受付では、この離脱がそのまま件数の減少になります。
2つ目は、回答者との連絡です。承認の仕組みは、社内の承認者に依頼を届けるために作られています。申請者である社外の相手に、不備の連絡や追加書類の依頼を送る経路は、別に用意することになります。
3つ目は、状況の共有です。社外の相手から「いまどうなっていますか」と問い合わせが来たとき、答えるための画面が必要です。承認の履歴は承認センターにありますが、窓口の担当者が1件ずつ探すことになります。
この3つに共通しているのは、承認より前と後にある作業だという点です。承認の仕組みは、承認そのものを効率化する道具であって、受付を回す道具ではありません。役割が違うため、機能が足りないというより、範囲が違うと考えるほうが正確です。
社外からの受付は、場面によって必要な仕組みが変わります。助成金・公募の受付は締め切りのあとに審査の工程が続き、講座の受講申し込みは開催日までに定員と支払いの状況を追います。どちらも承認の可否だけでは完結しません。自分の受付がどちらに近いかを先に決めておくと、必要な機能が絞られます。
通知の届き方を設計しないと、承認は遅くなる
承認フローを組んでも、承認者が依頼に気づかなければ日数は短くなりません。組んだあとに効いてくるのが、通知の設計です。
まず、承認者が普段どこを見ているかを確かめます。メールの受信箱を1日に何度も見る人と、チャットしか見ない人がいます。前者なら承認の依頼メールで足りますが、後者には届きません。チャットへの通知も併せて設定しておくと、待ち時間が目に見えて短くなります。
次に、督促を設計します。承認の依頼を出したまま何日も返答が無い場合に、誰に知らせるかを決めます。督促が無いと、止まっていることに誰も気づきません。3日で本人に再通知、5日で上位の役職者に知らせる、といった形が実用的です。
3つ目に、申請者への通知を設計します。受け付けたことを知らせる返信、承認された結果、却下された結果。このうち受け付けたことを知らせる返信は、忘れやすいのに問い合わせをもっとも減らします。送信した直後に自動で返す形にしておいてください。
4つ目に、通知の文面を決めます。依頼の題名に申請の区分と金額を入れておくと、承認者が受信箱の一覧で優先順位を付けられます。題名がすべて同じだと、開くまで中身が分かりません。
通知の設計は、機能の有無ではなく運用の問題です。同じ道具を使っていても、通知の届き方を決めた職場と決めていない職場で、承認までの日数は大きく変わります。
段数と件数が増えたときに、何が起きるか
組んだ直後は快適に動いていた流れが、運用を続けるうちに重くなります。原因は2つで、承認の段数と申請の件数です。
段数が増えると、流れの中の分岐が掛け算で増えます。1段の承認なら、承認と却下の2通りです。2段になると4通り、3段では8通りの経路を考えることになります。すべてに通知と記録を用意すると、設定の抜けが出ます。段数を増やすときは、途中で却下された場合の扱いを先に決めてください。「1段目で却下されたら、そこで終わりにして申請者に返す」と決めておけば、経路は増えません。
件数が増えると、別の問題が出ます。1つは、承認者の受信箱が依頼で埋まることです。依頼の題名がすべて同じだと、どれを先に処理すべきか分かりません。題名に区分と金額を入れておくと、受信箱の一覧で優先順位を付けられます。
もう1つは、記録の探しにくさです。件数が数百件を超えると、記録の一覧から目で探すのが難しくなります。絞り込みの条件を先に決めて、その条件で絞れる形に記録を作っておきます。よく使う条件は、申請の区分、期間、承認の状態、担当の4つです。
3つ目は、止まっている件の見つけにくさです。承認の依頼を出したまま返答が無い件が、件数が増えるほど埋もれます。督促の設定と合わせて、未返答の件だけを一覧にする形を用意してください。
段数と件数のどちらが先に限界に来るかは、申請の種類によります。社内の定型申請は段数、社外からの申し込みは件数が先に来ます。どちらの方向に伸びるのかを見込んでおくと、作り直しの時期を読めます。
足りなくなったときに、何を足すか
Formsと自動化の組み合わせで足りなくなったとき、選べる道は3つあります。
1つ目は、流れを作り込む道です。条件分岐を増やし、承認の段数を足し、別の仕組みと連携させます。自由度は高いものの、作った人以外が触れなくなる問題があります。担当者が変わったときに、誰も直せない流れが残ります。作り込むなら、流れの設計を図にして残す作業を同時に進めてください。
2つ目は、申請と承認に特化した道具に移す道です。承認の経路、代理承認、履歴、条件分岐が最初から用意されています。社内の定型申請が多い職場では、この道が合います。
3つ目は、受付の入口から見直す道です。フォームで受け付けた1件ごとに、担当と状況の札を持たせ、そこから直接返信できる形にします。社外からの申し込みが多い職場では、承認の機能を足すより、この形のほうが作業量が減ります。
3つのどれを選ぶかは、いま困っている作業がどこにあるかで決まります。承認が遅いことに困っているなら2つ目、承認のあとの連絡と追いかけに困っているなら3つ目です。両方に困っている場合も、同じ道具で両方を満たす必要はありません。社内の承認は既存の仕組みで動かし、社外からの受付は別の入口で受ける形にしている職場もあります。
移る前に確かめておくことが1つあります。いまFormsに溜まっている回答を、表形式で書き出せる形にしておくことです。書き出したものを次の道具に取り込めるなら、過去分を引き継げます。取り込みに対応していない道具を選ぶと、過去の申請を参照するために古い画面を残すことになります。移行の可否は、決める前に確かめてください。
料金の考え方も確認しておく項目です。申請の件数や実行の回数で費用が変わる形と、使う人数で決まる形があります。件数で費用が変わる形は、申請が増えたときに予算が読めません。料金のページで数え方そのものを確かめておくと、後から予算が崩れずに済みます。
作った流れを、引き継げる形にしておく
自動化で組んだ承認フローには、共通した弱点があります。作った人しか中身を把握していないことです。担当者が異動すると、誰も直せない流れが動き続けます。
引き継げる形にするために、4つを残します。
1つ目は、流れの図です。きっかけ、取得する情報、承認の依頼、結果による分岐、記録の書き込み。この順序を1枚の図にして、どこで何が起きるかを書きます。画面のスクリーンショットを並べるより、順序だけを書いた図のほうが後から読めます。
2つ目は、差し込んでいる値の一覧です。Formsのどの設問が、承認の依頼のどこに表示されるか。この対応を表にしておくと、設問を変えるときにどこが壊れるかが分かります。
3つ目は、承認者の決め方です。固定の1人なのか、条件で変わるのか。条件で変わるなら、その条件を文章で書きます。設定画面を見れば分かることでも、文章になっていると引き継ぎが早く済みます。
4つ目は、止まったときの見方です。流れが失敗したときにどこを見るか、誰に連絡するかを書いておきます。これが無いと、止まったときに申請が消えたように見えます。
この4つを残す作業に、半日かかりません。残さないまま運用を続けると、数年後に「触れないが止められない流れ」として残ります。組んだ直後の、記憶が新しいうちに書いておくのが確実です。
流れの数が増えてきたら、一覧を作って管理します。どの申請にどの流れが対応しているか、最後に手を入れたのはいつか。10本を超えたあたりから、一覧が無いと把握できなくなります。
受け付ける側から見ると、承認のあとに列が残る
承認フローが扱う範囲は、申請から承認までです。受付を回している人の作業は、そこで終わりません。
窓口には、承認の前後に次の作業が並びます。届いた内容の不備を確認して相手に連絡する。追加の書類を受け取る。いまどの件が誰の担当なのかを追う。結果を相手に伝える。問い合わせが来たときに、その件を探して現在の状況を答える。承認の仕組みだけを持つ形では、この列がすべて手作業のまま残ります。
残った作業が起こす事故は決まっています。返信したかどうかが表に残らないと、二重返信と返し忘れは必ず起きます。担当が決まっていないと、全員が「誰かが見ている」と思って誰も見ません。状況が1か所にまとまっていないと、問い合わせに答えるために複数の画面を開くことになります。
ここを埋める形として、フォームで受け付けた1件ごとに、担当と状況の札を持たせる方法があります。届いた申し込みが一覧に並び、いまどの段階にあるかが札で見え、そこから直接返信できる形です。送信されたあとの道具がそろっていることが、受付の作業量をそのまま決めます。どの機能がその範囲に入るかはできることのページに並んでいて、実際の画面の動きは動くところを見るから確かめられます。
いま使っている形で足りているかの見分け方は単純です。「先週この申し込みに誰が何と返信したか」を、1つの画面で見られるかどうか。見られるなら、承認の仕組みを整えるだけで足ります。見られないなら、承認より先に、受け取ったあとの記録を残す場所を決めるほうが効きます。いま使っているフォームとの違いはMicrosoft Formsとの比較で確かめられ、移行の方法や契約期間といった後から変えにくい点はよくある質問にも整理されています。
Formsで承認フローを組む作業は、承認の経路を作ることだけではありません。申し込んだ相手が、いまどこで止まっているかを知れる状態にするところまでが範囲です。そこまで設計しておくと、件数が増えても回し方は変わりません。
Q1. Microsoft Formsだけで承認フローは作れますか？
作れません。Formsは質問を並べて回答を集める道具で、回答に対して承認や差し戻しを行う機能は持っていません。承認フローを組むには、回答が届いたことをきっかけに動くPower Automateを組み合わせ、「承認 - 開始して承認を待機」のアクションを流れの中に置く形になります。
Q2. 承認者はどこから承認するのですか？
承認の依頼はメールで届き、受信箱から直接返答できます。Power Automateの承認センターから返答することもできます。承認者が普段どちらを見ているかで、届き方の設定を決めてください。メールだけに頼ると受信箱の下に沈むため、チャットへの通知も併せて設定すると待ち時間が短くなります。
Q3. この形で足りなくなるのは、どのタイミングですか？
申請の種類が10種類を超えたとき、承認の段数が3段以上になったとき、社外の人が申請するようになったとき、承認のあとに事務局の作業が続くようになったときです。どれか1つでも当てはまると、流れの設定が複雑になり、作った人以外が触れない状態になります。
Q4. 社外からの申し込みも同じ形で受けられますか？
受けられますが、3つの問題が出ます。組織のアカウントを持たない相手にログインを求めると離脱が起きること、社外の相手への不備の連絡や追加書類の依頼の経路が別に必要になること、問い合わせに答えるための画面が無いことです。社外からの受付はログイン不要のフォームで受け、届いたあとに担当と状況を持たせる形が現実的です。