FormsとPower AutomateでEntra IDのゲスト招待システム&棚卸システムをつくってみる(その1)

ゲスト招待システム

Entra IDには他のテナント(他社)のユーザーを招待する機能があります。Entra IDはユーザーを管理する仕組みですが、そのなかでゲストという種類のユーザーが作成されます。これにより、他社のユーザーに自社のSharePoint上のファイルにアクセスさせるというようなことが可能になります。

便利な機能ではありますが、やたらめったらゲスト招待を利用すると、自社のユーザーリストには他社のメールアドレスを持つユーザーがずらりと並び、気がつけば削除もしづらい状態になります。その理由は誰がなんの理由で招待をしていて、今現在とこれからもこのユーザーにアクセス権を与え続けていてよいのか、削除することで仕事に支障がでるのかが判断できないからです。

ところどころ、試行錯誤しながら勧めていますので、参考にして作成する場合には、ちょっと先を読みながら作ってもらえるとありがたいです。

招待したユーザーを管理しつつ、承認を経てゲストとして追加する

そこで、いつ誰がどんな理由でいつまでゲストをテナントに登録した状態にするかを管理できるようにしたいと思います。そのためのゲスト招待システムを作ります。

できるだけ開発負担が少なくて済むように、ユーザーはFormsに入力することで申請ができるようにします。

招待してよいのかどうかの判断は、申請を行ったユーザーの上司にしてもらいます。この上司の情報はEntra ID上の登録情報を使います。もし上司情報がない場合には、管理者に承認要求が飛ぶようにします。

登場人物

  • ゲストを招待したい人(申請者)
  • 申請者の上司
  • ゲスト(他社の人)
  • 管理者(ゲスト登録権限を持つ人、申請者の上司がいない場合に代わりに承認する人)

申請システムに必要なテーブル列

申請システムのテーブルはSharePointリストを使う想定です。とりあえず、こんな感じでしょうか?

  • 申請者メール:テキスト型
  • 申請日時:DateTime型 SPOリストの登録日時を使う
  • 承認者メール:テキスト型
  • ゲストメール:テキスト型
  • ゲスト氏名:テキスト型
  • ゲスト所属:テキスト型
  • 申請理由:テキスト型
  • 承認日時:DateTIme型
  • 棚卸期限:DateTIme型
  • ゲスト招待期間:Int型
  • 承認ステータス:テキスト型
  • 備考:テキスト型

ざっくり必要な列を考えましたが、SharePointリストでは適切な内部列名を英語でつけたほうがよいので、Copilotくんに提案をしてもらいます。

そうすると、こんな感じで提案してくれました!すごくないですか?

テーブル名も提案してもらいましょう。

GuestInvitationManagement という提案が気に入りました。利用するSharePointサイトを開き、ホーム>新規>リスト から新しいSPOリストの名前を指定して「作成」をクリックします。

提案された列名をもとに、SPOリストに列を追加していきます。

申請日時はレコードの登録日時を流用するつもりでしたが、再申請のことを考えると別レコードとして作っておいたほうがいいかな?

何日間ゲストとして存在させるか、最初の申請の段階で入力させようと思います。

ひととおり列を作り終えました。確認は右上歯車アイコンから「リストの設定」を開くことで確認、修正ができます。

リストができたら、画面の上部にある「フォーム」をクリックして「新しいフォーム」を作成します。

この方法でMicrosoft Formsを作成すると、Formsに入力した内容が自動的にSPOリストに追加されます。このあとの動きを少しだけお伝えすると、SPOリストのレコードが増えたことをPower Automateのクラウドフローで検知して後続の動作を実行するトリガーにします。

Formsにはアイコンを加えることができるようなので、ふたたびCopilotくんにデザインしてくれるようにお願いしてみました。なかなかビジネスっぽいアイコンを作ってくれました。

さて、Formsをつくるぞ!と思って編集した矢先に、「申請者」ってつまりこのFormsを入力する人なのだから、記録されるSPOリストの登録者を申請者とみなしたほうが、入力ミスも防げて確実じゃない?と思い直しました。

作りかけのFormsを削除yし、ApplicantEmail列を削除して、SPOリストにもともとある「登録者」を「申請者メール」に書き換えてみました。

入力させる項目にだけチェックをいれて、説明を加えました。

プレビューはこんな感じ。使うかどうかわかりませんが、「添付ファイル」の項目を任意のONにしています。申請書なりゲストに対する同意書PDFなりを添付させるのも良いかもしれません。

処理の流れを妄想する

さて、申請システムの申請ユーザーに対するインターフェイスをFormsで用意できたので、今度は裏の処理を作って行きましょう。

ひとまず妄想レベルですが、イメージはこのような感じです。

  1. Formsでユーザーがゲスト招待申請を投稿する
  2. クラウドフローがSPOリストの追加によってトリガーされる
  3. 入力されたゲストEmailがメールアドレスとして妥当か(正規表現が使える?)確認して、受付または却下メールを申請者へ送る(却下ならステータスを「却下」にして、備考に理由を書き込む。妥当ならステータスを「承認待ち」にして申請日を書き込む)
  4. 承認者ユーザーのメールアドレスに承認要求を送る。エラー担った場合は、Teamsチャネルへ投稿。管理者として承認して進むか、却下して申請者に差し戻しメールを送るかを選択。承認した場合は、上長(または管理者)のメールアドレスを承認者列に書き込む
  5. 承認が通ったら承認日時に書き込み、ステータスを「承認済み」に更新して次へ進む。30日間承認されない場合は、ステータスを「承認待ち30日期限切れ」に変えて申請者へメールを送る。却下の場合は、理由を含めたメールを申請者に送る
  6. 管理者としてEntra IDのゲストを登録する
  7. 登録が成功したら、SPOリストの棚卸期限列に、ゲスト招待期間の数字を加えた日付を登録する
  8. 登録が成功したら、承認者と申請者にメールで通知する
  9. 登録が失敗したら、管理者へ通知する(チャネル投稿)→Teamsチャネルを見て、エラーを確認し、手動でゲスト登録をしてSPOリストを書き換え、チャネルに行った対応を投稿する運用で回避。SPOリストにTeamsの投稿URLを入力できる列があっても良いかも。

ここまで作ってみて、もともとは上長をOffice365コネクターで取得するつもりだったけれど、よく考えたら上長設定をしていない企業だって多いよなぁ、と思い直し。承認者列はユーザー型にしてForms内で申請者に選択させるようにしようかと思います。

テキスト型からユーザー型への変更はできないっぽい。一回削除して列を作り直します。

いちど削除して以下のように追加しました。

Formsの中身はこんな感じになりました。

SPOリストへの追加をトリガー動作を始めるクラウドフローを作る

Formsで申請の投稿がされたことをきっかけに裏側の処理を走らせます。Power Automateを開いて マイフロー>新しいフロー>自動化したクラウドフロー をクリックします。 ちゃんとしたシステムならソリューションの中で開発したほうが良いかもですが、ソリューション化は後でもできるので、とりあえず動く状態を目指します。

適当なフロー名をつけて、トリガーとして「項目が作成されたとき」を選択して、「作成」をクリックします。

ひとまず動作の確認と、トリガーからどのような項目が取れるのかを確認するために「作成」の中に動的なコンテンツを適当に指定してみます。トリガーの中身としては申請者のEmailなどが body/Author/Email のような指定で取得できるようです。「作成」に入れ込んだときに、「Apply to each」が作成されないということは、配列化されていないので扱いやすそうです。

動的なコンテンツの項目の中に「申請者メール.Department」というのもあります。申請者は後々所属が変わったりしますので、申請時点の部署名をSPOリストに記録しておくのもアイディアとして良いかもしれません。申請者本人が退職していて、承認者もどこかに行ってしまったような場合に、部署名は棚卸の際の問い合わせ先として参考にできるからです。

まずはトリガーと中身を確認する「作成」アクションだけできたら、テスト>手動 で実行します。自動トリガーなので、実際にFormsからSPOレコードに1レコード追加されることでクラウドフローが走ればまずは成功です。

ゲスト招待のテストで入力、投稿を行います。一番下の承認者は、ユーザー型で列を作成したので、社内の人のメールアドレスの一部を入力すると候補が表示されて素敵です。ユーザー型にするとテキスト型と違ってメールアドレスの入力ミスを防ぐことができ、顔写真も表示されるのでご送信も防げます。

Formsなので、送信した後はこんな感じの表示になります。ここのメッセージは後で変更しておいたほうが良さそうですね。

自動的にクラウドフローが動作を初めて、申請者のメールアドレス、つまりFormsを入力したユーザーのメールアドレスが取得できました。

今日のところはここまで

おさらいです。

ゲストは一度招待したら、削除してよいのかわかりにくくなります。

ゲストを誰が招待したのかをはっきりさせ、ゲスト招待後一定の期間が過ぎたら、そのままゲストとして残すかどうかを申請をした本人に対して問い合わせを行うのが今回作ろうとしているゲスト招待システムです。

作りを簡単にするために、SPOリストに紐付いたFormsを申請用のインターフェイスとして使います。

SPOリストに行追加されたことをきっかけに、後続の処理をキックするために、クラウドフローの自動トリガーを使いました。このトリガーから申請者などの情報が含まれています。配列ではないのでループ処理を使わずに値が取れました。

次のステップ

フローで取得できた値をもとに、承認処理と、Entra IDへのゲスト追加処理、その間の進捗状況をメールで申請者へ伝える処理などを組み込みます。次回 「FormsとPower AutomateでEntra IDのゲスト招待システム&棚卸システムをつくってみる(その2)」をお楽しみに。

各ステップに応じて、SPOリストにはステータスを更新します。作りながら考えていますが、今のところ以下のようなステータスを想定しています。

  • 却下
  • 承認待ち
  • 承認待ち30日期限切れ
  • 承認済み
  • ゲスト
  • ゲスト追加失敗

どんな人が作っている?

お仕事でPower BIやPower Automateクラウドフローを中心にちょっとした自動化などを行っています。

QiitaやこのブログではPower Automateの話題を中心に投稿を行っていますので、ぜひ「いいね」してくださると励みになります。