Office 365 のライセンス有効活用、承認者がシステムにログインすることなくOutlookメールのみで承認フローを流す
Office 365 Business Premium, E1, E3などのライセンスで既に運用をしている場合、PowerAppsと関連するPower AutomateやOffice 365内での連携は無償でできることも多い。しかしながらCDS(Common Data Service)やSQL ServerなどOffice 365とは関係のないシステムと連携する場合PowerAppsの有償ライセンスを別途購入、ユーザーに付与しなければならない。 PowerAppsでOffice 365内でできることとして一例になるがSharePointやExcelを「データベース」として使うことができる。
詳細は https://memo.tyoshida.me/power-platform/powerapps/unofficial-powerapps-flow-license-chart/
今回のワークフロー
フォーム入力（PowerApps）→
ビジネスオーナ－承認/拒否（メール）※今回のフローでは「1人」の承認者が「1人」承認したら次に進む →
ITセキュリティ担当承認/拒否（メール）※今回のフローでは「1人」の承認者が「1人」承認したら次に進む →
IT作業者へ通知、作業終了入力（メール）→
関係者へ一斉完了通知（メール）
作成手順の例
SharePointリストまたはExcel Onlineで入出力したいデータのカラムを定義
（今回はSharePointを利用） →
PowerApps でSharePoint（またはExcel）と連携させフィールド表示させ並び替え、表示サイズの調整を行う→
Power Automateでフローの定義（変数が無ければAsk in PowerAppsを活用）→
Power Appsで「Ask in PowerApps」変数引き渡しを設定
ユーザー申請のPowerApps画面例
第一承認フロー時のステータスとメール
第二承認フロー時のステータスとメール
作業者作業中のステータスと作業完了時に押下するメール
作業完了後に関係者に通知するメール
データ変更履歴
必要ライセンス
PowerAppsへのアクセス方法
・ブラウザ（初回のみアプリへの直接URLでアクセス必要）
・PCのMicrosoftストアアプリ
・スマホアプリ
初回のみSharePointへの書き込み、メール送信するアカウントに関するアカウント紐づけが必要。
SharePointのリストをデータベースとして定義した設定例
PowerAppsやSharePointは共有必要（削除権限はく奪）、ワークフローは共有しなくても動く
Teamsで共有する場合、プリロードオプションが便利
PowerAppsボタンのコーディング例
"Form2"が今回のPowerAppsのフォーム名の場合。
※※※NULLの受け渡しはエラーになるようなので、空白を受け渡ししています。
・初期時に画面を新規入力にInitialize、ClearボタンやSubmitボタン（Power Automateに変数受け渡しの例）・・・SubmitのときはSubmit後に直前に記録した内容をPower Automateに受け渡し、受け渡し完了後に新規入力画面を呼び出すという形にしている
Power Automateフロー例
SharePointのレコードが特定できる場合、Created by Emailなど記録されているレコードの内容をメールに埋め込むことが可能です。
PowerAppsで入力した内容に加えSharePointの内容もメールに入れ込む例です。
Power AutomateでAsk in Powerappsを選び変数を作成後、PowerApps側からその変数に対して値を受け渡しします
2020/5/13 追記
複数の添付ファイルをSharePoint List にアップロードし
承認メールに全て自動添付させたい場合、添付ファイルがあるリストアイテムIDを特定、
その後、ファイル格納するArrayを宣言し、ファイルIdentifierを全件取得させる。
その後、ArrayにNameとContentBytesを格納させるがContentBytesはbase64(ファイルコンテンツ変数名)の計算式を使わないと上手くファイルが認識できなかった。
最後に承認メールのAttachmentsにArrayを指定すればファイルが全件添付される。
2020/5/18追記
SharePointで必須か否か、PowerApps側で必須か否かどちらでも制御ができ、SharePoint側で制御するとPowerApps側で自動反映されることがわかったが、汎用性をもたせるにはデータベース側のSharePointではなくアプリ側のPowerAppsで制御させたほうがよさそうなことがわかった。特にドロップダウン形式の場合の選択値をどうするかとかとかあるアプリでは必須だが別のアプリでは任意にしたいといった対応がアプリ側ならできるがデータベース側で実装してしまうと汎用性がなくなるため。また、SharePointではReadは自分のものだけ、Create/Editは自分のもの以外も可との制御ができるのでワークフローは回せるが申請内容を一覧表示させるというのは自分のものだけといった制御をすることで一定のセキュリティを担保することができることがわかった。
また、SharePointとの連携でAsk in Powerappsは最低1つSharePointリストレコードのIDで連携し、冒頭でSharePointのIDとレコードの紐づけをさせてしまえばPowerAppsから多数の変数の受け渡しを行うことなくSharePointの変数を活用できることもわかっている。（例でいうところSubmit for Approvalボタンで承認フローをキックする際に多数のLastSubmit変数を受け渡すことなくIDのみで何とかなりそう）SharePointのレコード確定を冒頭でしてしまい後続の処理はSharePointの変数を有効活用することがよさそうだ。
今後の改修課題/条件
・SharePointリストは5000件を超えると誤作動を起こすようなので、大量のトランザクションはこなせず必要に応じて移動、パージする必要がある。
・SharePointをステータスによって変更禁止、読み取り専用にする
・自分で申請したフォームのみ閲覧可などのセキュリティコントロール
・既に回っている承認フローに対して代理承認を強制上書きしてできないか？
・差し戻し対応
・申請済ステータスチェックアプリ