7
12

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

#PowerPlatform デザインパターン 承認・申請ワークフロー

Last updated at Posted at 2020-04-25

Power Platform で仕組みを作成するにあたり「自分だったらこうするかなー」というパターン、皆さん持っていませんか?そんな「自分だったらこういう設計にする!」という、所謂「デザインパターン」みたいなモノを記録しておこうかと思ったのでチャレンジする企画です。
言うても、中のヒトがそんな大そうなモノでもないので、飽きたらこの1回で終了するかもしれません。

前提条件

  1. Microsoft(Office)365 利用中
  2. ゲストユーザー追加は全体管理者以外禁止されている
    (※一般ユーザーはゲスト追加できない)
  3. Power Apps、Power Automate はエンドユーザーも利用可能

ユースケース

自テナントへのゲストユーザー追加を制限しているトコは多々あります。ゲストユーザーの追加が制限されている場合、追加をしたい場合は管理部門へ申請を必要とする運用になっていると想定されます。そして、その申請は Excel や Word の電子媒体に記載するか、既に自社で運用しているワークフローシステムによる管理が多いかと想定されます。(よもや、紙に書いて印鑑リレーして提出、なんてトコロはありませんよね?)

昨今、テレワークが増加してきた関係で、Teams や SharePoint Online によるクラウドを利用した情報共有が加速していますよね。その流れで、クラウドになれてきた一般ユーザーは、自社メンバー以外のパートナーや顧客とも情報共有をしたくなってきます。そうなると、ゲスト追加の申請数が多くなり管理者側の運用負荷をUpさせます。さて、前述の申請書をチェックしてからゲストを招待するまでの作業、1日に何個処理できますか?

と、長い前置きをしましたが。まとめると「情シスがゲスト追加の申請をいちいちチェックして、承認したら手作業でゲスト追加をするのがメンドクサイ」という状況である、と。この作業を可能な限り省力化したい という状況だ、としましょう。

アーキテクチャー

はい、当方だったらどうするか?
Power Apps で申請内容を記載して申し込みをするアプリを用意します。申請時に登録された情報はデータストアに保存します。申請内容がデータストアに登録された場合に発火するトリガーで、Power Automate のフローを起動します。
※データストアを介在させる意図は後述。

image.png

Power Apps と Automate の境界は下図になります。

image.png

Power Apps 補足

申請をアプリにする必要はなく、直接データストアに入力させれば Power Automate のみで利用できます。なぜ、ソレをしないのか?等をつらつらと。

  • ゲスト招待はメールアドレスが必須
    • メールアドレスの入力チェックは厳密に実施しないと事故のモト
    • Power Apps におけるメールアドレスのチェックは、こちらの記事 参照
  • スマホやタブレット等、マルチデバイスでの申請も可能になる
  • 誰が申請したのか?がアプリ経由で入手可能
  • 登録されたデータが「申請履歴」になるので情報が一元管理ができる

Power Automate 補足

Automate 観点でいくと、Apps から直接フローを起動しても良さそうなのでは?と感じる方がいるかもしれませんね。なぜ、そうしないのか?等をつらつらと。

  • データストア登録トリガーで発火する=Automate は作成者のみで運用可能
    • フローを共有する必要が一切ない
    • 前提条件で記載した「管理者のみゲスト追加可能」を維持するためには、アプリから直接起動させる=フローの共有はNGですよね?
  • ゲスト登録には Graph API を利用せざるをえない(現状
    • 参考情報:招待状の作成
    • フローの共有が必要だった場合、有償ライセンスは何本必要ですか?
  • 例えば、SharePoint Online のリストから申請フローが自動生成できますよね?
    • データストア(データソース)はお好みで選択いただければOKなのですが(可能であれば)自動で作成対応してくれるトコは活かしたいですよね

お断り

今回は、有償ライセンスが必要なプレミアムコネクターのHTTPコネクターを利用する設計になります。記事作成時点で Automate に Azure AD へゲスト登録するアクションが無いのでショウガナイね。

また、実装に関する詳細は記載しません。全ての意図も記載しておりません。そのため「ここがうまくデキないんですけど」等のご質問には対応いたしません。個人的な思いですが、自分たちで調べて、実装して試してみて、使ってみて初めて身につくモノがあると考えております。是非、挑戦を。
どうしても・・・、という場合はお仕事として対応できる方(※当方含めて)等にご相談ください。

「こういう設計のが良いのでは?」や「こういうデザインもあるよ」というご意見は大歓迎です。

まとめ

今回のユースケースが「ゲストユーザーの登録申請」にしたので、有償ライセンスが必要なデザインになっています。例えば「有給申請」のような内容であれば、365ライセンスに含まれる範囲(for Office 365 ライセンス)で実現可能でしょう。
ゲスト追加の申請をメールでやれないだろうか? → やれます。その場合、Power Apps アプリが不要になりますね。等々、様々な方向性は存在します。目的にあわせて、適宜デザイン(=設計)を柔軟に実施してください。

また、Power Apps と Automate のフローを組み合わせる際の「当方の基本姿勢」は別の記事でも解説しております。興味のある方はあわせてご確認ください。

 PowerApps + Microsoft Flow 組み合わせ時の設計思想

Power Platform、とくに Power Apps でアプリ作成がある程度可能になってくると、だんだんと「巨大な仕組み」にしようとして「全部1つのアプリで完結しよう!」みたいなノリになってる方を見かけます。個人的に、巨大な仕組み・システムはお勧めしません。

image.png

超巨大で冗長で不便な基幹システムみたいなモノで苦い経験をされた方、少なく無いと思います。皆さんが、同じものを作ってはいけませんよ。

image.png

『小さくて鋭いツール』で生産性をUpして、楽して業務をたのしみましょう。

それでは、皆さま、素晴らしい Power Platform Life を!

7
12
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
7
12

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?