社内の申請系にFormsをつかうのはアリかとおもう
今年のゴールデンウィーク、特に出かける予定もなかったので、前から気になっていた Microsoft Forms と Power Automate の連携を試してみました。
テーマは「社内の申請システムをノーコードで作ってみる」です。
9回にわたって開発の様子をブログに書いたのですが、この記事ではその中で得た気づきや「やってみて初めてわかったこと」をまとめてみようと思います。
システムの概要
今回作ったのは、社内でゲストユーザーを招待するための申請フローです。
- 申請者がFormsで申請
- 承認者が承認
- 承認されたらゲストがテナントに登録される
- 申請時に90日・180日・360日のいずれかの期限を設定
- 期限が近づくと、延長 or 削除の選択を促すメールが申請者に届く
- 延長されなかったゲストは、期限到達時に自動で削除
という流れです。
「ちょっとした申請フローなら、これで十分じゃない？」と思えるくらいには動いてくれました。
システムの構成
このシステムは、以下の3つの要素で構成されています。
- ゲスト招待申請用のForms（SPOリスト連携版）
- SPOリスト追加をトリガーに、承認とゲスト追加を行うクラウドフロー
- 定期実行トリガーで、期限チェックと削除を行うクラウドフロー
作ってみて初めて気がついたことっておおいよね
🔸 SPOリストの必須列は「項目の更新」で上書きしないといけない
🔗 その２より
クラウドフローでSPOリストの値を更新するには「項目の更新」アクションを使いますが、必須列は変更がなくても値を再指定しないとエラーになるんですね。
同じ値で上書きするのはちょっと無駄な気もしますが、仕方ない。項目が多いと指定ミスにも注意が必要です。
🔸 列名を考えるのにCopilot Chatが使えた
🔗 その１より
SPOリストの列名を決めるとき、日本語の列名を箇条書きでCopilot Chatに渡すと、自然な英語名を提案してくれるのがとても便利でした。
🔸 正規表現はOffice Scriptで代用
🔗 その２より
クラウドフローには正規表現がないので、Excel + Office Script をSharePointに置いて、スクリプトでチェック処理を実装しました。
今回はゲストのEmailアドレスの妥当性チェックに使いました。
🔸 承認はタイムアウトも大事
🔗 その３より
承認される・却下されるだけでなく、期限までに何もされなかった（タイムアウト）ケースも考慮する必要があると気づきました。
待機時間の指定にはISO 8601形式を使うのですが、これもCopilot Chatに聞いたらすぐわかりました。
🔸 「ユーザーの作成」ではゲスト登録できない
🔗 その４より
ゲストを追加するには、Graph APIを使う必要がありました。「ユーザーの作成」アクションではダメなんですね。
プレミアムコネクタを使わない方針でしたが、ここだけはHTTP要求アクションを使いました。
🔸 テストを繰り返すので「静的な結果」が便利
🔗 その５より
何度もテストする中で、**承認済み状態を再現できる「静的な結果（プレビュー）」**がとても便利でした。
「なんとなく知ってたけど、ちゃんと使うと便利」ってやつです。
🔸 ゲストの状態確認には externalUserState
Graph APIの externalUserState を使えば、招待メールを承諾したかどうかがわかります。
「ユーザープロフィールの取得（V2）」でこの列を追加すれば、HTTP要求を使わなくても取得できました。
🔸 スコープ内のエラーは result 関数で確認
🔗 その６より
スコープの中でどこが失敗しているのかを確認するには、result関数が便利でした。
今まで使ったことなかったけど、知っておくと安心。
🔸 承認処理にはコンカレンシー制御が必要
🔗 その７より
複数の承認待ちがあるとき、コンカレンシー制御をONにしないと順番待ちが発生します。
今回のシステムを作った目的のひとつが「承認を使いこなす」だったので、ここは大きな学びでした。
🔸 ゲスト削除にはUPNじゃなくオブジェクトIDを使う
🔗 その８より
Graph APIで削除リクエストを送るとき、UPNに # が含まれているとエラーになるんですね。
「ユーザープロフィールの取得」アクションでオブジェクトIDを取得して、それを使えばOKでした。
おわりに
FormsとPower Automateを使った申請システム、思った以上に実用的でした。
ノーコード／ローコードでここまでできるなら、ちょっとした社内業務の自動化には十分アリだと思います。
ああ、なるほどね！と思ってもらって少しでもお役にたてるものであれば良いなと願うばかりです。