Sharepoint リストをフィルターし、Power Automate の条件に使ってみる

Power Automate の条件が複雑になる場合、Sharepoint リストに切り出すことが可能です。
2021.06.30

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

Microsoft Flow、もとい Power Automate とは、様々なアプリケーション同士での処理の自動化ツールです。例えば、

  • 上司からメールを受信したらSlackで通知を受け取る
  • Outlookの添付ファイルをGoogle Driveに保存する

など。様々なテンプレートも用意されているので初心者もすぐに使い始められます。

同様のサービスに IFTTTZapier がありますが、Microsoft が提供しているために Office365 関連サービスとの連携が良いです。

はじめに、失敗談

まず今回自分がやりたかった自動化の処理には、Sharepointリストなんて全然必要ありませんでした。完成させてからもっとシンプルで分かりやすい方法に気付きました。

それでもこの方法が必要となる場面はあるかとは思いますので、自分にとっては無駄の産物になってしまいましたが、世の知見となるよう、このブログを綴ります...

本稿ではフロー作成の詳細ではなく、作成段階の考慮事項やハマりどこを中心にご紹介します。

 

ちなみに具体的には、 Power Automate 内で指定している条件の一覧を、誰でも更新できるよう切り出したいというのがやりたいことでした。

以前こちらのブログで導入した処理で、以下のように Power Automate フロー内の条件分岐に差出人や件名の条件を入力しています。

この条件一覧を、タイトルの通り Sharepoint リストに切り出すことで、ざっくり以下のような処理を Power Automate で構成しました。

  1. 共有メールボックスに添付付きメールが届いたら、Sharepoint リストを取得
  2. メールの差出人や件名でリストをフィルター
  3. フィルターしたアイテムのタイプがAの場合は、処理1(OneDriveのフォルダaへ添付ファイルを保存)、タイプBの場合は処理2、該当アイテムがなければ何もせず終了。
  4. 処理したメールをメールボックスの対応済みフォルダへ移動

これ、エラーハンドリングなど含めるとかなり複雑なフローになります。ですが、次のように条件を Outlook ルールで追加しておけば、リストなしで超シンプルにできました。

  1. [Outlook ルール] 差出人や件名で該当するメールは、フォルダA、フォルダBへそれぞれ移動
  2. [Power Automate] フォルダAにメールが入ったら、処理1。フォルダBなら処理2。

(以下のようなルールとフローをAとB用にそれぞれ作る)

※ 上図のままだと、Outlook ルールで先にメールをフォルダへ移動するので、 Power Automate のフローがもし途中で失敗してもメールはフォルダに移動済みとなってしまい、対応済みとの区別がつきません。ファイル保存の処理が成功したらメールを既読にすると良いかも。

完成サンプル

上述のような事情がありますので、フローはあくまで概要をご参考としていただけましたら。

[フロー 1/3]

(1) トリガー:共有メールボックスのInboxに、添付付きの新着メールが届いた場合とします。

(2) Get items:Sharepoint リストアイテムを取得。
この「Filter Query」の中で、OData フィルタクエリを使って差出人アドレスでフィルタしています。これで Filter array ブロックを1つ省略できます。

Sharepoint リストは以下のような構成です。

列タイプ 備考
Type 選択肢 必須項目で、値は2種類
From address 文字列 必須項目
Subject includes 文字列 任意項目なので空の可能性あり

(3) Filter array:取得したリストを件名でフィルタ。
「メールの件名に "Subject includes" の文字列が含まれる場合」というフィルタ条件です。

ダイナミックコンテンツを選択して「[Subject] contains [Subject includes]」とできますが、[Subject includes]は任意項目で値が空の可能性があり、その場合は String と Null を比較しようとしてエラーとなってしまいます。

そのため、coalesce 関数を使って、coalesce(items()?['Subject_includes'],'')と指定します。

[フロー 2/3]

(4) Create HTML table:フィルタした結果をHTMLテーブル化。
これは処理内で必須ではありませんが、ログとして、実際にどの値がフィルタで取得されたか確認するのに役立ちます。

Filter array ブロックを重ねる場合は、値には必ず最後の Filter array の [Body] を選択しましょう。

(5) Switch:フィルタされたリストアイテムの数に応じて処理を分岐。
1件の場合がメインの処理 (Apply to each) で、0件ならば何もせず終了、2件以上 (デフォルト) ならリストが異常ということで、今回はSlackへメッセージをポストするよう構成しています。

こちらも、条件には最後の Filter array の length() を指定します。

 

以下、1件の場合の処理で、0件とデフォルトの場合は割愛します。

[フロー 3/3]

(6) Apply to each:フィルタされたリストアイテムごとに次の処理を行う。(既に1件の場合と条件を絞っているけど、システム上必須)

(7) Switch:リストアイテムのType列の値に応じて処理を分岐。
Type列の値が "invoice" の場合は処理1、それ以外(デフォルト)なら処理2を行う。

Power Automate を使うべき?

冒頭で "初心者でもすぐに使い始められる" と言いましたが、逆に少し高度な処理にはかなり悪銭苦戦すると感じました。

IFTTT や Zapier と比べると、恐らくできることの可能性はかなり広くて、単純なところで所々クセがあり、それを理解するのに多少なり技術者としての知識が求められる...けれどツールならではの「コードなら簡単だったのに」とプログラマを悩ませる部分もあったりして。

その辺に関して、次の記事がとても納得できたので、導入を検討される際にご参考ください。

また今回の失敗談のように、 Outlook ルールなど統合するアプリ側の機能で解決できる可能性もありますので、どこまで Power Automate での処理が必要なのかをあらかじめよく切り分けた方が良いでしょう。

以前のブログで導入した自動化処理では、弊社が使用している会計ツール(Lexoffice)や銀行(Qonto)と連携している Zapier を使っていますが、共有メールボックスでの操作はZapierではできないために、全体の処理を分けて Power Automate を併用しています。

[図の左半分がPower Automate、右半分がZapierで自動化、図の下部は自動化前に必要だった手動フロー]

Sharepoint リスト vs Excel

今回はSharepointリストを採用することにしましたが、Excelで一覧を作って、Power Automate上で同様に扱うことも可能なようです。

Sharepoint リストのメリットは、RDBMS テーブルの GUI 操作のように、列のタイプ(文字列、数値、Yes/No等)を指定したり、必須列かどうか指定したりすることができ、データも手動で入力するには分かりやすく間違いが少ない点です。
Excel だと編集の自由度は高いものの、列のタイプ指定や必須列といった設定をするにはExcelスキルが求められますね。

一方のデメリットですが、今回リストの形式を途中で変更したいと思った際にかなり不便を感じました。Excelにしておけばこんな苦労はなかったのにと...しかし、逆に言えばExcelでは簡単に複数セルの値を変更・削除できるため、誤ってデータが操作されてしまう可能性は高いでしょう。

作成してからあまり変更を加えないようなリストならば、Sharepoint リストを使うのが有効かなと思いました。

Sharepoint リスト作成時の注意点

作りながらリストを改修した結果、以下2点は先に知っておきたかったなと思いました。

  1. カラム名は慎重に決め、なるべく後から変更しない。
  2. Excelからデータを取り込む場合、いくつか制約があることを理解する。

リストは、Sharepointトップページ > Site Contents > New > List より作成します。まっさらのリストから作成するか、既存リストから複製するか、Excelテーブルからインポートするか決められますが、作成後はExcelで更新することはできません。

1. カラム名はなるべく変更しない

カラムを追加すると、初期作成時の名前を元に一意の名称が付与されるようなのです。このIDは、後からリストでカラム名を変更しても変わりませんし、現時点で変更することもできません

例えば、以下のリストの列「Subject includes」は元々「Note」という名前で作成していて後から用途を変えて名前変更したものです。ダイナミックコンテンツとしてはUI通りの名前が表示されますが、アドバンスモードで指定する場合にはここはIDで指定する必要があります。

コードで確認(Peek code)する際やログでの表記もIDが使われるので、失敗時の調査などで分かりづらくなってしまいます。

(画像上: ベーシックモード(ダイナミックコンテンツを使用)、下: アドバンスモード)

用途が変わるなど列名を変えるなら、なるべく早めに列ごと削除して新規追加した方が良いです。

2. Excel リスト取り込みの制約

1の問題を解消するため、リストを一通り作った後に、Sharepointリストのページから一度 [Export to CSV] でエクスポートし、インポートで新しいリストを作成し直しました。

ただし、Excelインポートできるのは作成時のみで、作成済みのリストをExcelで編集したり、インポートで更新したりすることはできません。

また、エクスポートはCSV形式ですが、インポートはExcel形式しかサポートしておらず、あらかじめリストをテーブル化しておく必要があります。(ここはもう少し親切に改善していってほしいところ)

※テーブル化 - 具体的には、Excelでリストを開いたら、「テーブル」を挿入し、以下のようにデータ範囲を選んで1行目をヘッダとするよう指定します。テーブルデザインは任意です。

Yes/No 形式を使う場合は、Excel上では値を 1/0 で入力しておき、インポート時にタイプをNumberとして取り込みます。Sharepointへ取り込んだ後に、タイプをYes/Noに切り替えることができます。(TRUE/FALSEでもNumberが指定できるけど、切り替える時に値がすべて消えました...)

なお、上記は悪い例でして、Excelインポートで列名にスペースは入れない方が良いです。「Subject includes」のIDは「Subject_x0020_includes」となってしまいました。例えばIDを「Subject_includes」としたい場合はその値を列名に指定して取り込み、後でリスト上で列名を変更してスペースに置き換えましょう。


以上、入りは簡単だけど、少し先に進むと大変な Power Automate。私の失敗を糧に、どこかでどなたかの役に立てば幸いです。

なお英語ではナレッジもかなりたくさんありますが、私の経験ではグーグル検索では望ましい投稿にうまく辿り着かず。情報を探す際には同じキーワードでも Microsoft Community 内で直接検索してみた方が、類似記事を見つけることができました。