オーナーなしTeamsをメンバー自身に救出させる~Forms/Flow/GraphAPIを利用し、無駄な管理者運用を削減する~

このエントリでは、オーナーなしTeamsのメンバーがFormsから問い合わせをすると、条件を満たした場合、自動的に問い合わせたメンバーをオーナーに昇格させる仕組みの作成方法を記載します。

が、本当に伝えたいのは

Forms/Flow/GraphAPIを組み合わせることで管理者権限の一部だけをユーザーに切り出し、既存の管理者作業が自動化でき、管理者もユーザーもハッピーになれる！

ということです。今回のフロー以外にも…

  • メールが着信しているか確認するための、メールログの検索
  • SharePointライブラリの容量拡張
  • メーリングリストへの社内メンバー追加

といった、判断が単純で例外が少ない作業は、容易に置き換え可能と思われます。

今回作成するフロー

こちら。

Forms/Flow/GraphAPIを組み合わせることで、ユーザーからのインプットを元に判定を行い、自動で処理が行われるようにできます。

作成したフローのソース

githubに置いておきました。

teraco/rescue-noowner-teams

このエントリ、画面ショット中心で画面の中の文字列は画像のままなので詳細パラメーターコピペしたい！という場合は、githubのソースをご確認ください。めんどくさがりやですいません。なおこのエントリの画像もgithubのソースもテストテナントのテナントIDやアプリケーションIDが入っていますが、自分のものに置き換えて利用してください。

※ テストに使用したアプリケーションは既に無効化されています。

Forms/Flow全体像

フロー全体像です。次のスライドからセクション毎に説明します。

1.Formsの作成

チーム名だけを入力可能なFormsを作成します。シンプルですね。

2. Formsの値読み取り

ひとまず上記Flowで入力された値と裏で送信されているユーザーIDなどを読み取ります。あと、後半で使う変数もここで定義しています。

Apply to eachは勝手に作られますので、ひとまず上から順番にFlowを作っていきましょう。

3-1. ユーザー所属Teams読取り

Formsでユーザーが申請したチームにユーザーが実際に所属していることを確認します。そのために、ユーザーが所属しているTeamsの一覧を取得します。

List joinedTeamsは先日GAされたTeams関係のAPIです。で、ポイントですが、List joinedTeamsのユーザー指定がユーザーオブジェクトIDしか受け付けずUPNが使えない事です(これで2日ほどハマりました)。

よって前段でGet a userしてユーザーのユーザーオブジェクトIDを特定してからjoinedTeams実行してます。

3-2. 処理対象Teams特定

ユーザー所属Teamsと、Formsに入力されたTeamsの名前が一致していることを確認します。ここは普通のif文。

4-1. グループオーナー有無確認

ユーザーが申請したTeamsにユーザーが所属していることは確認できましたので、実際にそのグループのオーナーが0人であることを確認します。オーナーが存在する場合、管理されているTeamsであり、ユーザーが勝手にオーナーに昇格しようとしている、ということですので…。

4-2. グループオーナー昇格

条件を満たしたので、申請者をグループオーナーに昇格させます。

動かしてみましょう

所有者が0人になったチームが存在します。

ユーザーがFormsから申請します。

申請者が所有者になります。

出来上がった業務フロー

before

after

ということで情シスの介入が不要となりました。

まとめ

こまごまとしたユーザー問い合わせに対して、ほぼ判断なく事務的に実行している情シス業務をForms/Flow/GraphAPIに肩代わりさせて楽になりましょう！

おまけ

Flow vs LogicApps

上記の処理はFlowではなくLogicAppsでも実装できます。ではどちらがよいか?

  • マイクロソフト社の推奨
    • Flowはユーザー自身がユーザーの仕事を便利にするための個人的なツール、LogicAppsは情シスが組織全体に使わせるフローを作るための物
  • 現実
    • 機能差
      • Flowはスマホ用のボタンをトリガーとできたりするが、それ以外ではLogicAppsの方が多機能
      • 逆に言うとFlowで間に合う機能で実現できるならFlowでよい
    • 課金体系
      • FlowライセンスはOffice 365に含まれており、一定回数以下の実行なら無料
      • LogicAppsはステップあたりの課金であり、1回の実行から課金されます。

よって手軽に使えて機能的にもLogicAppsに比べて遜色のないFlowがよく使われていた印象です。

しかしながら、2019年2月1日からHTTPコネクタを利用するためには、Office 365 のFlowライセンスではなく、Flowの有料ライセンスが必要となり、FlowとLogicAppsの機能差が広がります。

※ このエントリのフローもLogicAppsかFlowの有料ライセンスがないと実現できなくなりました。

Updates to Microsoft Flow and PowerApps for Office 365 – Microsoft Tech Community – 289589

今後もこのような流れが続きFlowとLogicAppsの機能差が拡大するならば、組織全体で動作を保証しなければいけないものはLogicAppsで作るのがよいかもしれません。

Flowをもっとうまく書く

先日、太田さんがツイートしていたigniteのFlowセッション動画がお役立ちです。

Microsoft Flow and PowerApps: Advanced workflow and business process management – BRK2230 – YouTube

13:58くらいから解説があるのですが、今回のフローのようにifのネストが発生する場合にそれを避ける方法など、実用的なテクニックが記載されています。

前述の通り、FlowではなくLogicAppsを使う場合、課金体系がステップ毎になるので、少ないステップでLogicAppsを実装することがお金に直結します。ので頭を使ってパズルを解くようにLogicAppsを作る必要があります。非常に楽しそうですね！

その他各種テクニック(メモ)

GraphAPIアプリケーション登録方法

こちらに全てが書かれています。

Microsoft Flow の HTTP アクションにある Active Directory OAuth 認証で Microsoft Graph API を利用する | idea.toString();

2018年12月現在、「アプリ登録」と「アプリ登録(プレビュー)」があり、登録手順が若干違いますが…。アプリ登録の概念を理解すれば登録できるはず…です。

JSONスキーマの確認

Flowで実際に流して確認してもいいが、GraphAPIでAPIをたたき、戻ってくる値を確認するのが一番容易。慣れている人はPostmanやPowerShellを使用可能。

JSONスキーマがエラーになる

上記の方法で自動認識させると厳密な型判定を行うので、実際に流してみてNull値があった時にエラーとなる。型指定を解除するか、使用しない項目なら単純削除すればOK。

Posted by tera