Teamsで複数人にメンションをかける方法が知られています。リンク先の方法では、複数のメールアドレスが配列として得られています。一方で、複数人の宛先を記述するよくやる方法として、カンマ,やセミコロン;で区切って複数のメールアドレスを書き並べた文字列を作ることがあります。本記事では、このようなケースでカンマ区切り文字列から複数のメールアドレスの配列を生成します。

なお、この記事で紹介するフローであれば、カンマ区切りで連結していない単独のメールアドレスが入力であるときも正常に動作します。

フローの全体像

Power Automateのフローは以下の通りです。各処理の中身は後述します。

各アクションの解説

カンマ区切りのメールアドレス

組み込み>データ操作>作成アクションを使用して、このフローで使用するカンマ区切りテキスト形式のメールアドレスを格納します。実際のフローでは、PowerAppsトリガーなどを経由して値を渡します。

ここでは “aa@exaple.com, bb@example.com, cc@example.com” のような形でメールアドレスが記述されています。

メールアドレス配列の初期化

組み込み>変数>変数を初期化するアクションを使用して、カンマ区切り文字列から配列を生成します。

split関数に分割する文字列と、分割する位置を指定する文字(ここではカンマ,)を与えることで、文字列を分割します。注意すべきことに、split関数を使うだけではPower Automateのフローで繰り返し操作の対象となる配列になりません。split関数の出力は文字列です。変数を初期化するアクションに配列のもとと「値」に、このsplit関数の出力を渡す必要があります。

式にはsplit(outputs(‘カンマ区切りメールアドレス’),’,’)のように記述します。

この配列は「メールアドレス配列」という名前で後段で使用できます。

メンショントークンの初期化

各メールアドレスから生成したメンショントークンを格納します。組み込み>変数>変数を初期化するアクションを使用して、空の配列を用意します。

Apply to each

組み込み>コントロール>それぞれに適用するアクションを使用して、「メールアドレス配列」から各メールアドレス要素を取り出してメンショントークンを生成する処理を行います。

ユーザープロフィールの取得

標準>Office365Users>ユーザープロフィールの取得(V2)アクションを使用して、メールアドレスからユーザープリンシパル名を取得します。@mentionトークンを取得するのにユーザープリンシパル名が必要なのに対して、所属組織によってはメールアドレスがユーザープリンシパル名と異なる場合があるためです。

ここで入力には以下のように記述しています。
trim(items(‘Apply_to_each’))
trim関数はスペースを削除する関数です。カンマ区切りテキスト形式でメールアドレスを入力する際に、メールアドレス間にスペースを入力することが多いので、スペースを除去する処理を介在させた方が安全です。

ユーザーの@mentionトークンを取得する

Teamsの当該アクションで、ユーザープリンシパル名から@mentionトークンを生成します。

配列変数に追加

組み込み>変数>配列変数に追加アクションで、生成した@mentionトークンを配列に格納します。

メンショントークンの結合

組み込み>データ操作>結合アクションで、「メンショントークン」配列の要素を結合します。「次を使用して結合」はカンマ,を使用していますが、半角スペースなどでもOKです。

チャットまたはチャネルでメッセージを投稿する

「メンショントークンの結合」アクションの出力をメッセージの中で使用すれば、メンションがかかります。

なお、複数のメンショントークンを作成し、結果としてひとつのメッセージの中で同じユーザーに対して何度もメンションがかかるような本文ができたときは、本文中で最初にそのユーザーが登場する部分だけメンションがかかったように表示されます。

---

なお、Teamsの制限としてひとつのメッセージでメンションできるユーザーの上限は20人までです。20人以上に同時にメンションするにはタグメンションやチームメンションの使用が必要です。

ユーザーへのメンションに拘る場合、メッセージを投稿した上でスレッドに返信する形でメンションを並べる形が考えられます。。PowerAppsでの実装例を別のページに示します。PowerAutomateではChunk関数を使ってメンションの宛先を分割する方法があります。

Power AutomateでTeamsのスレッドに返信のメッセージを投稿するには、チャネル内のメッセージで応答しますを使用します。新しいスレッドを建てるチャットまたはチャネルでメッセージを投稿するに比べて少々わかりにくい名称ですし、リファレンスを読んでもよくわかりません。こういうときは、Power Automate上で実際に作ってみるのが早いです。

投稿者はFlow BotまたはUserから選択します。投稿先はChannelの一択です。

Message IDはチャットまたはチャネルでメッセージを投稿するのメッセージIDを入力します。チャットまたはチャネルでメッセージを投稿するの出力は、メッセージ ID、メッセージリンク、会話 IDの3個です。なお、私の環境で試したところ会話IDはチャネルIDと同じでした。

TeamとChannelは投稿先のチームとチャネルを指定します。カスタム値の入力を使って、チームIDとチャネルIDから指定することもできます。チームIDとチャネルIDの取得方法は別の記事で紹介しています。

ところで、チャネル内のメッセージで応答しますの出力にもメッセージIDがあります。こちらのメッセージIDに対して返信しようとすると、メッセージが見つからないというエラーがでました。スレッドのトップのメッセージにしか返信できないのかもしれません。

Power Automateでチャネルへの投稿を自動化したい場合、チャネルIDとチームIDが必要です。この二つのIDをユーザーが取得しやすい「チャネルのリンク」から取り出す方法を紹介します。

Teamsのチームの各チャネルには直接チャネルにアクセスできるURLがあります。このURLはTeamsのチャネル名の右にある三点ボタンからメニューを開き「チャネルへのリンクを取得」を選択することで取得できます。ここで得られるURLには、チャネルIDとチームIDが含まれています。したがって、「チャネルのリンク」を入力として、「チャネルID」文字列と「チームID」文字列を出力とするフローを組むことができます。

フローの全体像

Power Automateのフローは以下の通りです。各処理の中身は後述します。

各アクションの解説

チャネルのリンク
データ操作の作成アクションです。「チャネルへのリンクを取得」で取得したURLを与えています。このアクションの代わりに、トリガーで入力するようにしたり、Power Appsから渡すようにしておくと活用しやすいでしょう。

URIデコード
データ操作の作成アクションです。入力には、作成アクション「チャネルのリンク」の出力を用いて「decodeUriComponent(outputs('チャネルのリンク'))」のように指定します。
「チャネルへのリンクを取得」で取得したURLは本来URIで使用できない文字列をエンコードした形式になっています。これを本来の文字列に直す変換操作であるURIデコードを行います。

URIを配列に分ける
データ操作の作成アクションです。入力には、作成アクション「URIデコード」の出力を使って式を「split(outputs('URIデコード'),'/')」と指定します。
チャネルのリンクは、以下のような構造をしています。「/」で文字列を分割すれば、5番目がチームID、6番目のgroupID=以降がチャネルIDであることがわかります。なお、0番始まりで数えている点に注意してください。

https://teams.microsoft.com/l/channel/{チャネルID}/{チャネル名}?groupId={チームID}&tenantId={テナントID}

チャネルID
データ操作の作成アクションです。入力には、作成アクション「URIを配列に分ける」の出力を使って式を「outputs('URIを配列に分ける')[5]」と指定します。
末尾が@thread.tacv2という文字列だと思います。

テキストの位置の検索
テキスト関数のテキストの位置の検索アクションです。入力の「テキスト」には、作成アクション「URIを配列に分ける」の出力を使って式を「outputs('URIを配列に分ける')[6]」と指定します。また、入力の「検索テキスト」に「groupId=」と指定します。
「outputs(‘URIを配列に分ける’)[6]」で取得した文字列から「groupId=」の位置を割り出し、後段の操作でこの文字列よりも後ろの部分を抜き出します。

部分文字列
テキスト関数の部分文字列アクションです。入力の「テキスト」には、作成アクション「URIを配列に分ける」の出力を使って式を「outputs('URIを配列に分ける')[6]」と指定します。また、入力の「開始位置」に式「add(outputs(‘テキストの位置の検索’)?[‘body’],8)」と指定します。
「outputs(‘URIを配列に分ける’)[6]」で取得した文字列から「groupId=」の開始位置を割り出し、「groupId=」の文字数8を加えることで、「groupId=」の後ろの文字列を抽出します。

チームID
データ操作の作成アクションです。入力には、作成アクション「部分文字列」の出力を使って式を「split(outputs('部分文字列')?['body'],'&')[0]」と指定します。
「&」の後ろに続くtenantIdが不要なので、「&」で文字列を分割したうえで配列の先頭(0番目)の文字列を取り出します。
チームIDの文字列はGUIDの形式になっています。

取得したチームIDとチャネルIDの使い方

Teamsの「チャットまたはチャネルでメッセージを投稿する」アクションを使う場合は、投稿先をチャネルとして上で、チームとチャネルに取得したIDを指定します。取得したIDを設定するには「カスタム値の入力」を選択します。

PowerAppsの「PowerAppsまたはFlowに応答する」アクションを使う場合は、出力追加でテキストを選択し、取得したIDの出力を追加します。

PowerAutomateのインスタントクラウドフローは、フローの所有者のほかに「実行のみユーザー」という権限でほかのユーザーに共有できます。この機能を使って、フローを実行するユーザーAから別のユーザーBへTeamsチャットでメッセージを送信することを考えます。

Teamsコネクタのアクションを調べていくと、チャットまたはチャネルでメッセージを投稿するを使用すればチャットのメッセージを送れるような気がします。ところが、チームのチャネルに投稿する方法とグループチャットに投稿する方法はわかりやすいわりに、普通のチャットすなわち個人から個人へチャットする場合はどうしたら良いかぱっと見でわかりません。そこで、このページでは個人から個人へチャットを送る方法を2つ紹介します。

フローの例

フローの例を下図に示します。分岐の右側のフローが方法1、左側が方法2です。

方法1: グループチャットの宛先に1人だけ入れる

それアリ？という感じがしますが、これが最もそれらしい振る舞いをします。

まず、チャットの作成アクションで追加するメンバーに宛先となるメールアドレスを入力します。ここで、宛先のメールアドレスがひとつだけの場合、フロー実行者と宛先の2者間のチャットを指定する会話IDが返ります。グループチャットのタイトルを指定する欄がありますが、タイトルを何にしようと影響はなく、常に2者間の通常のチャットを指定する会話IDが返ります。

こうして得られた会話IDを使って、チャットまたはチャネルでメッセージを投稿するアクションを動作させます。投稿者をユーザーとすればフローの実行者がチャットを送信することになります。投稿先をグループチャット、グループチャットには先ほどの会話IDを入れます。メッセージの記入欄が表示されるので、そこに動的なコンテンツを含むメッセージ本文を記入します。リンクを張りたい場合などは、ボタンを押してHTMLを記述します。

チャットの作成アクションの宛先について注意が必要な点として、実行ユーザー自身を指定できません。もしチャットの宛先にフローの実行者が入る可能性がある場合は、後述する方法2を使用します。

チャットの作成アクションは、宛先が複数のときと今回試したような宛先が1つのときで挙動が違うのに注意してください。宛先が複数あるとき、すなわちグループチャットを作成する場合にはグループチャットの構成メンバーとタイトルが同一であろうとチャットの作成アクションが動作するごとに異なる会話IDが生成されます。

方法2: フローボットとのチャット

チャットまたはチャネルでメッセージを投稿するアクションで、投稿者を「フローボット」、投稿先を「フローボットとチャットをする」に設定します。
宛先の指定は、Recipientに受信者のメールアドレスを指定するだけで十分です。
メッセージの記入欄が表示されるので、そこに動的なコンテンツを含むメッセージ本文を記入します。リンクを張りたい場合などは、ボタンを押してHTMLを記述します。

番外編: チャット相手を指定してTeamsクライアントを立ち上げる

URIスキーマを使うと、宛先を指定した状態でTeamsクライアントのチャット画面を開かせることができます。
宛先のメールアドレスがexample@onmicrosoft.comのとき
https://teams.microsoft.com/l/chat/0/0?users=example@onmicrosoft.com
のように書きます。
PowerAppsのLaunch関数でこのようなURIスキーマを開かせることで、通常のTeamsクライアントでチャットを送る動作をとれます。

番外編: Power AppsからTeamsコネクタを使ってメッセージを送る

Power AppsのSharePointコネクタでリストを読み込んだり、Outlookコネクタでメールを送信したりするのと同様に、Teamsコネクタでメッセージを送信できます。私はやり方がわからなかったのでAutomateで処理しましたが、Power AppsからTeamsのグループチャットに直接メッセージを送る方法を真似すればできそうな気がします。

Power Apps上で処理が完結できると、エラー処理を含めてユーザーにフィードバックを与えながら処理をできるので、全体としてUXが向上すると期待できます。

追記: PowerAppsから直接Teamsにメッセージを送信する方法をまとめました。

PowerAppsではシナリオとして典型的な操作を行うための画面が用意されています。複雑な機能を実現するのにシナリオで用意された画面を改変することで自分の目的を達成することができます。この記事では、予定表の表示に使用する「カレンダー」シナリオを拡張する例を紹介します。

シナリオで用意された画面の構成を調べる

改変するには元がどうなっているかを理解する必要があります。「カレンダー」シナリオで用意された画面の構成を調べてみましょう。

PowerAppで新しい携帯電話レイアウトのキャンバスアプリを作成します。続いて、新しい画面を使いする操作から、シナリオの「カレンダー」を選択します。

操作に成功すると、次のような画面が表示されます。画面上部のドロップダウンはPowerAppsで表示する予定表を選択するのでしょうか。ドロップダウンの右のカレンダーアイコンはまだよくわかりません。画面の下部はまずドロップダウンから予定表を選択せよとの指示です。

アプリの動作を確認するため、画面右上の再生ボタンかAltキーを押しながら画面をクリックします。ドロップダウンから「日本の休日」を選択すると、画面が以下のように変わります。

この画面を見ると、「カレンダー」シナリオの画面構成がどうなっているか、だいたい見当がつくでしょう。画面上段は表示すべきカレンダーの選択、画面中段は日付の選択、画面下段は選択した日に入っている予定の一覧です。

また、ドロップダウンを操作したときに画面の大部分が表示されたことから、ドロップダウンに主要なデータ操作が仕込まれていると予想できます。そこで、ドロップダウンのOnSelectやOnChangeを見てみましょう。

ドロップダウンのOnSelectを見ると、何行にもわたるコードが記述されていました。各行を読んでいくと、Office365Outlookコネクタを利用して予定表に登録されている予定の一覧を読み出すGetEventsCalendarViewV2を実行している行があります。この行ではClearCollect関数を使って、読みだした予定の一覧をMyCalendarEventsという名前のコレクション(テーブル)に保持するようだとわかります。

予定表から読みだされるデータはどのような形式かを確認します。PowerAppsの編集画面からコレクションの中身を確認してみましょう。次のような横に長い画面が出てきます。

ここで大事なのは列名とその列にどのようなデータを入れることになっているかです。また、多くの列がありますがほとんどPowerAppsのアプリでは使用していないデータです。一通り列名とデータを確認すると、このあと使いそうなデータは次の4つくらいでした。

列名	入っているデータ(予想)	入っているデータの型(予想)
End	予定の終了年月日時刻	時刻
Location	予定の場所	テキスト
Start	予定の開始年月日時刻	時刻
Subject	予定の題名	テキスト

Outlookの予定表から読みだした各予定の情報は高々この程度です。これらがClearCollect関数でMyCalendarEventsという名前のテーブルに格納されているとわかったら、同じ形式のテーブルを用意してやれば、「カレンダー」シナリオの画面をそのまま使いまわせるでしょう。具体定期には、SharePointリストで上の表にまとめたような列を持つリストをOutlook予定表の代わりにデータソースにできるはずです。

SharePointリストに登録したアイテムを予定として読み出す

前のセクションで予定を入れるのに必要なSharePointリストの列は4つ(End, Start, Location, Subject)だろうと見積もりました。このような列を持つSharePointリストを作ってみます。

EndとStartは「日付と時刻」型の列とします。時間を含めるを「はい」にして列を作成します。LocationとSubjectは1行テキストとします。

試しにデータを入れてみました。ここでは「Outlook代替」という名前のリストにしています。

ここで作成したSharePointリストをPowerAppsで読み込んでみましょう。

まずSharePointリストをPowerAppsから参照できるようにします。「データ」>「データの追加」>「SharePoint」で作成した「Outlook代替」リストを指定します。

次にSharePointリストのデータをPowerAppsの「カレンダー」シナリオに合うように読み込みます。単にMyCalendarEventsという名前のテーブルに「Outlook代替」リストの中身を流し込めば十分です。下の例では「SharePoint読込」というボタンのOnSelectに以下のような関数を定義しています。

ClearCollect(MyCalendarEvents, Outlook代替);

「日本の休日」カレンダーには存在しない「hoge」なるイベントを予定表に表示できました。「Outlook代替」で仮に登録したデータが表示されています。

ついでに表示される項目を変更してみましょう。上の図で太字のhogeと表示されているのはSubject列の値です。この部分のTextにはThisItem.Subjectが定義されています。これをThisItem.TitleにすればTitle列の値が表示されます。

「カレンダー」シナリオでは、開始時刻Start、件名Subject、所要時間(終了時刻Endと開始時刻Startの差分を分単位で表示)、場所Locationを表示する構成になっています。これを置き換えたり、追加したり削除したりすることで、自分の用途に必要十分な予定表を作れるでしょう。

予定表に表示される予定の条件を変更する

「カレンダー」シナリオの初期条件では、選択した日付に開始される予定が一覧に表示されます。予定を一覧表示するギャラリーのItemsは次のように定義されています。Text関数はDateTimeFormat.ShortDateで年月日を返します。

SortByColumns(Filter(MyCalendarEvents, Text(Start, DateTimeFormat.ShortDate) = Text(_dateSelected, DateTimeFormat.ShortDate)), "Start")

それでは、複数日にまたがる予定はどうなるでしょうか？先に作成した「Outlook代替」リストには25日から27日またがる予定「ほげ」が入っています。しかし、この予定表では26日や27日に予定「ほげ」が表示されません。

関数を書き換えて、日をまたぐ予定も表示されるようにしましょう。SortByColumnsはただの並べ替えですので、まず注目すべきはFilter関数の中身です。

Filter(MyCalendarEvents, Text(Start, DateTimeFormat.ShortDate) = Text(_dateSelected, DateTimeFormat.ShortDate))

予定の開始日時Startと予定の終了日時Endを使って、選択した日(0時から24時)にかかる予定を表示するようにするにはどうしたらいいでしょうか。状況を整理するため、下図を見てください。表示したい予定の条件は何通りかありますが、表示したくない予定は「終了時刻が選択日の0時より前」と「開始時刻が選択日の24時以降」の2パターンであることがわかります。

「終了時刻が選択した日の0時よりも前の予定」と「開始時刻が選択した翌日0時以降の予定」はいずれも選択した日にかかる予定ではありません。したがって、これの否定Notを取ればいいわけです。選択した日の0時_dateSelectedを使って以下のように書けます。

日付の大小関係を比較するにはDateTimeValue関数で日付を数値に変換します。また、日付の計算にはDateAddまたはDateDiff関数を使います。日付の計算は特殊なので、使い方の例も見てみましょう。

Filter(MyCalendarEvents, 
    Not(
        Or(
            DateTimeValue (End) < DateTimeValue (_dateSelected),
            DateTimeValue (Start) >= DateTimeValue (DateAdd( _dateSelected, 1, Days))
        )
    )
)

否定Notで書くと一見してわかりにくいので、ド・モルガンの法則を使って書き換えておきます。「(AまたはB)の否定」は「(Aの否定)かつ(Bの否定)」に同値です。日本語で表現すれば、予定の終了日時が選択日の0時以降でありかつ予定の開始日時が選択日の24時よりも前ということです。日本語で表現しても、それっぽい感じがします。

Filter(MyCalendarEvents, 
        And(
            DateTimeValue (End) >= DateTimeValue (_dateSelected),
            DateTimeValue (Start) < DateTimeValue (DateAdd( _dateSelected, 1, Days))
        )
    )
)

これで当日にかかる予定で複数日にまたがるものを拾えるようになりました。

「カレンダー」シナリオでは、予定が入っている日付の下に小さい丸が表示されます。これの予定が入っている判定は前述の条件と同じく予定の開始日が日付と一致するです。前節で改変したように、複数日にまたがる予定がある場合に、予定がかかるすべての日に対して小さい丸を表示するようにしてみましょう。

小さい丸のVisibleプロパティは次のように指定されています。

/*Visible if calendar events are found on this day*/               
CountRows(Filter(MyCalendarEvents,
 DateValue(Text(Start)) = DateAdd(_firstDayInView,ThisItem.Value,Days)
)) > 0 
&& !Subcircle1.Visible 
&& Title2.Visible

予定の開始日時のDateValue(年月日)が、この日と同じ
かつSubcircle1(選択された日表示)がVisibleでない
かつTitle2 (日付) がVisibleである
という意味です。

1行目のCountRows関数に与えている当日の予定を抽出するFilter条件式を改変すれば目的を達成できそうです。
上の例から、カレンダーの一覧表示において、各日付はDateAdd(_firstDayInView, ThisItem.Value, Days)で表現できることがわかりました。これは各日付の0時を指す日時になります。予定がその日にかかるかを判定するには、予定の終了がその日の0時よりも後であって、かつ予定の開始が翌日0時よりも前であれば良いです。翌日0時は上の例にならってDateAdd(_firstDayInView, ThisItem.Value + 1, Days)と書けます。に予定がかかるかを判定したいので、基準となる日付は一覧の最初の日と最後の日です。したがって、Filter関数を次のように書き換えることになります。

/*Visible if calendar events are found on this day*/               
CountRows(Filter(MyCalendarEvents, 
        And(
            DateTimeValue (End) >= DateAdd(_firstDayInView, ThisItem.Value, Days),
            DateTimeValue (Start) < DateAdd(_firstDayInView, ThisItem.Value + 1, Days)
        )
    )
) > 0 
&& !Subcircle1.Visible 
&& Title2.Visible

以上でSharePointリストをソースとしたPower Appsカレンダー表示が完成です。

追加出費なく使える範囲でPower Platformを使い倒すため、データソースをSharePointリストだけで頑張る方法を調べました。

Power Appsのフォームコントロールで「個人」型データを指定する

編集フォームでリストに書き込む

詳細な説明はリンク先を参照

フォームで個人型に対応する値をメールアドレスなどから構成する場合は、対応するカードのUpdateやDefaultを以下のように指定します。

{
　Claims: "i:0#.f|membership|" & User().Email,
　DisplayName: User().FullName
}

Patch関数でリストに書き込む

詳細な説明はリンク先を参照

Patch関数の更新で個人型のレコードを書き込む列名に対して、以下のような値を指定します。

Claimsにメールアドレスが正しく入ってれば、Displynameはじめほかの値は適切な値に置き換えてリストに保存される模様。

{
    Value:"",
    '@odata.type':"#Microsoft.Azure.Connectors.SharePoint.SPListExpandedUser",
    Claims:  "i:0#.f|membership|" & Lower(User().Email),
    Department: "",
    DisplayName: "",
    Email: "",
    JobTitle: "",
    Picture: ""        
  }

Power Appsで取得した画像をAutomateを経由せずにリストに格納する

詳細はリンク先を参照

• PowerAppsで画像を保存・閲覧する
• Power Appsにおける画像の扱いについて

画像をJSON形式で扱うことで、リストの複数行テキスト列に格納できます。この方法であれば、SharePoint内に画像ライブラリや画像の保存フォルダを用意する必要がありません。

画像を文字列で扱えるといっても、フォームコントロールを介してリストにデータを送ることはできません。代わりに、Patch関数またはCollect関数でSharePointリストにアイテムを追加します。

JSON形式で画像を扱うとき

JSON関数に画像を読み取るコントロールのphotoやimageプロパティを渡します。ここでは、グローバル変数ImageJsonにカメラコントロールCamera1で取得した画像を設定するコードを紹介します。

Set(
 ImageJson,
 JSON(Camera1.photo,IncludeBinaryData)
);

SharePointリストに投稿するとき

JSON形式の画像ImageJSONをSharePointリストの複数行テキスト列GAZOに格納します。Patch関数を使った場合は次のようになります。

Patch( リストの名前,
  Defaults( リストの名前 ),
 { Title: "タイトル列の値",
   GAZO: ImageJSON
  }
 )

JSON形式で格納された画像を表示するとき

複数行テキスト列の値を読むと、ダブルクォーテーションで囲まれた文字列が返ります。このダブルクォーテーションを除去する操作をします。画像コントロールなどのimageプロパティに以下のような設定を行います。
ここではリストの2番目のレコードのGAZO列の値を表示します。

Substitute( Index( リストの名前, 2).GAZO,"""","")

---

SharePointリストのアイテム数(行数)制限

リストのアイテム数にはいくつかの上限が存在します。リストを読み込むサービスによる制限もあり、注意が必要です。

明確な上限数ない注意点

PowerAppsで大量のデータを読み込ませると処理しきれずに動作が不安定になります。

明確な上限数・閾値

100

Power AutomateのSharePointコネクタ「複数の項目を取得する」アクションでは、既定の読み込み件数が100です。設定を変更すれば5000件まで行けます。詳しくはリンク先をあご覧ください。

500

Power Appsが読み込む件数は既定が500件です。設定変更で2000まで行けます。これ以上はうまく委任を使ってください。

2,000

PowerAppsで読み込める最大の件数です。これ以上の件数があるデータソースを使用する場合は、委任できる関数で2000件以下に絞って読み込む必要があります。

PowerAppsの初心者だと2000件以上のデータソースは扱えないと思っている方もいますので、委任の考え方を身に付けてこの壁を突破しましょう。

5,000

SharePointリストのビューが一度に処理できる上限です。リストの並べかえなどが適切に行えない場合があります。

5000以上のアイテム数が入ったリストを操作する場合は、委任とインデックス列を意識する必要があります。インデックス付の列の設定を忘れずに。

SharePointリストの5000件問題として有名な閾値ですが、真の上限ではありません。「委任とインデックス付列」を意識していれば大丈夫です。

30,000,000

SharePointリストに保存できるアイテム数の上限です。存在するアイテム数が3000万件を超えないようにサービスを設計しましょう。

3000万行のデータを手軽さが売りのSharePointリストでやるのかという観点はありますが、業務システムだと平気で5年10年使われることもありますので限界まで余裕を持っておきたいですね。

Power Appsを使って、オフィス内で荷物をやり取りする宅配ロッカーのような仕組みを作ります。

情報をやり取りする手紙がメールに置き換わっても、小包のような荷物の配送は依然として大量に存在します。郵便局が扱う手紙が減っても荷物の宅配が増加しているのはその一例です。オフィスの中で荷物を配達するのに、宛先の人のデスクに荷物を置いておくというやり方があります。一方で、最近ではフリーアドレスのようにオフィス内に決まった居場所を持たない働き方が増えています。決まった居場所・デスクのない方へ宛てた荷物を受け渡すための仕組みとして、宅配ロッカーのような仕組みを考えてみましょう。

問題の整理

オフィス内で荷物をやり取りするために必要な機能を宅配ロッカーを参考に考えてみましょう。

• 荷物を一時的に保管できるスペース(ロッカー)がある。
• 宛先の人物に、荷物が保管スペースへ納品されたことを知らせる。
• 宛先の人物に、荷物を回収するように催促する。
• 宛先の人物が荷物を回収したら、その保管スペースに新たな荷物を設置できるようになる。

他にも、世間の宅配ロッカーには宛先の人物以外が荷物を取り出せないといった機能があります。これは不特定多数の利用者がいる場合に必要ですが、小規模なオフィス内では省略しても問題ないと考えます。また、形状もロッカーである必要はなく、テーブルなどモノを置ける場所に区切りや仕切りを施せば十分です。

また、利用ケースとして、外部から届いた荷物を配送する場合だけでなく、同じオフィスで働く従業員間で荷物をやり取りするケースも想定します。

設計

ソフトウェア

• 各保管スペース(ロッカー)の情報を管理するSharePointのリスト
• 各保管スペース(ロッカー)の情報を配達員または利用者が書き換えるためのPower Appsアプリ
• 利用者に納品通知や回収の催促を送るためのPower Automateフロー

ハードウェア

• 荷物を一時保管するためのスペース
  広めのデスクをテープ
• 各保管スペース(ロッカー)に対応するPower Appsアプリを呼び出すためのURLを埋め込んだQRコード
• 利用方法を案内する掲示物

業務のフロー

荷物の預け入れ

配達員は保管スペースに荷物を設置します。また、配達員は保管スペースに掲示されたQRコードをスマートフォンで読み込むことでPower Appsアプリを起動します。
配達員はアプリを通して、荷物の受取人を選択します。このとき配達員から受取人に対して伝言があれば、伝言を記入します。受取人と伝言を記入してアプリから送信すれば、配達員の手続きは完了です。
Power Appsアプリから送信されたデータはSharePointのリストに格納されます。SharePointのリストを監視しているPower Automateのクラウドフローが受取人に対して通知を送ります。通知には、荷物が届いた旨、どの保管スペースに荷物があるかの情報、配達員が誰かの情報、配達員からの伝言が記載されます。

荷物の受け取り

受取人は保管スペースで荷物を回収します。また、受取人は保管スペースに掲示されたQRコードをスマートフォンで読み込むことでPower Appsアプリを起動します。
受取人はアプリを通して、荷物を回収したことを送信します。
Power Appsアプリから送信されたデータはSharePointのリストに格納されます。SharePointのリストを監視しているPower Automateのクラウドフローが受取人に対して通知を送ります。通知には、荷物を回収したことを確認する旨が記載されます。

荷物回収の催促連絡

未回収の荷物がある場合、カレンダーベースのPower Automateで当該荷物の受取人に通知を送ります。特定の日数(1週間など)を超えて放置されている場合、配達員にも通知を送ります。荷物の放置が通知された場合、配達員は受取人の所属グループ同僚や上司に対して荷物の回収を催促します。

---

作り方

各保管スペース(ロッカー)の情報を管理するSharePointのリスト

荷物のやり取りに必要な情報を一元的に管理します。

どのロッカー(保管場所)を操作するかをID列で指定します。

列名	列名(内部)	列の型	目的
タイトル	Title	一行テキスト	人の目で見てわかりやすい各保管スペース(ロッカー)の名前を示します。 SharePointのリストで自動生成されるタイトル列を使用します。
ID	ID	数値	各保管スペース(ロッカー)と紐づけます。 SharePointのリストで自動生成されるID列を使用します。
受取人	Receiver	個人	荷物の宛先(受取人)をユーザーで指定します。
荷物あり	hasItem	はい/いいえ	荷物が設置されているか否かを示します。荷物がある場合は「はい」、荷物がない場合は「いいえ」です。
配達人	PostedBy	個人	荷物を各保管スペースに設置したユーザーを指定します。
荷主	Sender	一行テキスト	組織外部から荷物を発送した荷主の社名や名前を示します。荷物を各保管スペースに設置したユーザーではありません。
伝言	message	一行テキスト	配達員から受取人への伝言を示します。
更新日時	Modified	日付	最後に情報が更新された日時を示します。 SharePointのリストで自動生成されるModified列を使用します。

SharePointのリストで作ったイメージが次の図です。

---

各保管スペース(ロッカー)の情報を配達員または利用者が書き換えるためのPower Appsアプリ

SharePointのリストに対して、PowerAppsの編集フォームコントロールによる編集操作を行います。荷物があるかないかをhasItem列で判別し、hasItem列が「はい」の場合は荷物の回収動作、hasItem列が「いいえ」の場合は荷物の預け入れ動作を行います。

荷物の預け入れ動作 hasItem列が「いいえ」の場合

預け入れ動作用のスクリーンを表示します。

荷物を設置しようとする対象のロッカー名およびIDを表示します。

入力欄として、宛先人のユーザー選択を必須とします。必須でない項目として、荷主の名前と宛先人への伝言を入力できるテキストボックスを用意します。
この入力欄に対して「登録」ボタンを用意し、SubmitFormで入力欄の情報をリストに登録します。また、リストのhasItem列を「はい」に変更します。

荷物の回収動作 hasItem列が「はい」の場合

荷物の回収動作用のスクリーンを表示します。

荷物を設置しようとする対象のロッカー名およびIDを表示します。また、その時点で設定されている荷物の宛先ユーザー名、荷主の名前、宛先人への伝言、更新日時、荷扱人を表示します。

入力欄として、「荷物回収」ボタンだけを表示します。このボタンが押されたとき、リストのhasItem列を「いいえ」に変更します。

---

利用者に納品通知や回収の催促を送るためのPower Automateフロー

リストの変更があったときに動作するフローと、定時で動作するフローの2つを作ります。前者は荷物の預け入れと回収に関する通知、後者は回収の催促に使用します。

荷物の預け入れと回収に関する通知

「自動化されたクラウドフロー」をSharePointの「アイテムが作成または変更されたとき」トリガーで実行します。

トリガーからは、アイテムが変更された後の最新の情報がフローに渡されます。
リストのhasItem列が「はい」のときは荷物が預けられたことを意味します。このとき受取人に対して荷物が届いたので回収するように連絡します。また、荷物を預けたユーザー(配達人)には入力を受け付けた旨を通知します。
リストのhasItem列が「いいえ」のときは荷物が回収されたことを意味します。このとき受取人には入力が受け付けられたことを通知します。また、配達人には荷物が回収されたことを通知します。

回収の催促

「スケジュール済みクラウドフロー」を1日ごとに実行します。

宅配ロッカーリストをSharePointコネクタ複数の項目の取得ですべてのロッカーのデータを取得します。取得したデータに対して、Apply to eachで個々のロッカーごとのレコードを取り出します。ここでhasItem列がはいであれば荷物があることになりますから、hasItem列の値を条件に代入します。条件で比較するときに注意が必要なのが、hasItemと比較する対象は式エディタでtrueと入力するという点です。ベタ書きで「はい」や「true」と書いても一致判定してくれません。
hasItemがtrueのときだけ、Teamsのチャットまたはチャネルでメッセージを投稿するアクションを使って、受取人にメッセージを送ります。

---

アプリ作成の詳細

道具

• PowerApps数式と関数のリファレンス

各保管スペース(ロッカー)の情報を配達員または利用者が書き換えるためのPower Appsアプリの作成詳細

画面遷移

アプリが読み込む情報によってユーザーに求める動作が変わります。そこで、まずは画面遷移の構成を考えます。

PowerAppsのアプリ起動時に表示する画面は、ツリービュー>画面>AppのStartScreenで設定できます。If関数を使って、アプリが読み込むデータに基づいて適切な画面を表示できるように設定します。

荷物がすでにロッカーに存在する場合は、荷物の回収動作をします。荷物がない場合は、荷物の預け入れ動作をします。これらはSharePointのリスト宅配ロッカーにある情報を読み込めばhasItem列の値で判定できます。
SharePointのリスト宅配ロッカーのID列の値をロッカー番号として使いクエリパラメータLockerID=#の形で与える場合、表示すべき画面の分岐は次のようになります。hasItem列がはいTrueの場合は荷物の回収動作、いいえFalseの場合は荷物の預け入れ動作という名前の画面からアプリがスタートします

If(LookUp(宅配ロッカー,ID=Param("LockerID")).hasItem,
   荷物の回収動作,
   荷物の預け入れ動作
)

ここでもう一つ考えたいのが、エラー処理です。SharePointのリスト宅配ロッカーのデータがないLockerIDを指定されたり、そもそもLockerIDの値が与えられていない場合、アプリは正しい処理をできません。そのような場合、早めにユーザーへ警告したほうがよいでしょう。そこで、IsBlankOrError関数を使って、SharePointのリスト宅配ロッカーのデータを見つける動作を正常に行えなかった場合に失敗画面へ遷移するようにしておきます。

If(IsBlankOrError(LookUp(宅配ロッカー,ID=Param("LockerID"))),
    失敗画面, 
    If(LookUp(宅配ロッカー,ID=Param("LockerID")).hasItem,
        荷物の回収動作,
        荷物の預け入れ動作
    )
)

これでアプリ起動時の画面遷移ができました。ほかに後で出てくるデータ送信が成功したときのための成功画面も作っておくとよいでしょう。

荷物を預け入れる動作画面をつくる

まずは、荷物がない場合つまりhasItemが「いいえ」のときを考えます。これは新しく荷物を設置して、受取人に連絡する業務フローです。

「編集フォーム」コントロールを用意します。これをForm1と呼びます。Form1のデータは、SharePointのリストで作成した「宅配ロッカー」リストを使用します。Form1のプロパティ>データはDataSourceが「宅配ロッカー」、DefaultModeがFormMode.Editです。ここで編集対象のロッカー番号を指定して、指定したアイテムだけを編集したいと考えます。テキスト入力コントロールを挿入し、名称を「ロッカー番号入力」とします。ロッカー番号入力にロッカー番号を記入して、ロッカー番号がIDと一致するアイテムを編集対象とするには、Itemを以下のように書きます。
LookUp(宅配ロッカー,ID=Value(ロッカー番号入力.Text))
LookUp関数はデータテーブルから1個のレコードを抽出する関数です。第1引数はデータソース(リスト)の名前、第2引数は条件式です。ロッカー番号入力.Textでロッカー番号入力コントロールに記入された文字列を読み取ります。IDは数値なのでロッカー番号入力.Textを数値変換するようにValue関数にかけます。

ユーザーに手作業をさせると、必ずどこかで間違いが生じます。いまロッカー番号を手入力するような形で作りましたが、アプリ起動時のURLから自動的にロッカー番号を設定できるようにしましょう。画面遷移のパートで書いたように、Param関数を使ってURLから文字列を取り出すことができます。FormのItemを次のように記述すれば、Param関数から直接ロッカー番号LockerIDを読み出すことができます。

LookUp(宅配ロッカー,ID=Value(Param("LockerID")))

続いて、フォームで編集する項目を変えてみましょう。
Form1のプロパティ＞フィールド>フィールドの編集で、編集対象とする項目を編集できるようにましょう。ここでは、Title, Receiver, hasItem, Sender, message, PostedByを編集対象に加えます。

まず、hasItemはユーザーが値を入れるのではなく状態に応じて「はい/いいえ」が適切に変化するようにします。いまは荷物がないとこりに荷物を設置する場合を考えているので、操作をしたあたはhasItemが「はい」になるようにします。
ツリービューからhasItem_DataCard1のプロパティを開き、詳細設定のDefaultをtrueにします。trueは「はい」を意味します。逆にfalseは「いいえ」です。また、ユーザーが操作できないないように非表示します。同じく詳細設定のVisibleをfalseに設定します。

次に、受取人Receiverを工夫します。
表示がReceiverだと英語がわからない人に通じないので、受取人と表示されるようにします。ReceiverのDataCardでDisplayNameを”受取人”にしておけば、ほかの部分も連動して変わります。

Receiverはリストに「個人」型を設定したので、PowerAppsのForm1でも対応するUser型のデータを扱います。いまReceiver_DataCard1の下にDataCardValue2がある状態を考えると、DataCardValue2には選択されているユーザーのDisplayNameが表示されます。したがって、DataCardValue2で選択されているユーザーUserはDataCardValue2.Selectedで参照できます。たとえばDataCardValue2.Selected.Emailとすれば、選択されているユーザーのメールアドレスを取得できます。これを応用して、選択されているユーザーの姓だけを取り出すことができます。
Office365ユーザー.UserProfileV2(DataCardValue2.Selected.Email).surname
DataCardKey2の詳細設定のTextを以下のようにすることで、「受取人: 佐藤様」のような表示にできます。
"受取人: "&Office365ユーザー.UserProfileV2(DataCardValue2.Selected.Email).surname&"様"
ちなみに、このように表示項目に関数を仕込む場合は、関数がエラーを吐く場合に備えてIsBlankOrError関数でエラー処理を組み込んでおくと良いです。

PostedByもアプリを開いたユーザーが指定すればいいだけなので、同様にVisibleをfalseにしておきます。次にDefaultをアクセスしているユーザーにしたいのですが、これが一筋縄に行きません。Power AppsからSharePointのリストに送信するデータの形式をSharePointのリストの個人型に合わせるため、フォームで送信する値を工夫する必要があります。解決方法はリンク先を参照してください。工夫が必要になる原因はPowerAppsとSharePointのリストでデータ形式が不一致を起こすためです。なんのためのローコードか。

アプリを開いているユーザーを指定する最小の設定では、PostedBy_DataCard1 > DataCardValueのDefaultSelectedItemsを以下のように記述します。

{
　Claims: "i:0#.f|membership|" & Lower(User().Email),
　DisplayName: User().FullName
}

最後に送信ボタンを設置しましょう。
「ボタン」コントロールを挿入します。詳細設定のデータ>Textには「荷物を登録」のような文言を記入します。このボタンで重要なのはアクション>OnSelectにフォーム送信アクションを設定することです。
SubmitForm(Form1)
でForm1の内容がSharePointのリストに送信されます。

フォームの送信に成功したことがユーザーわかるようにするため、「正常に完了しました」とだけ表示する画面に遷移させます。フォーム送信時に画面を遷移させるには、Form1のプロパティ詳細設定のOnSuccessに以下のように記述します。ここで遷移先のスクリーン名を成功画面としています。
Navigate(成功画面)
一方で、OnFailureはfalseのままでよいです。入力必須の項目が未入力の場合に警告を表示するような動作はFormの方で勝手にやってくれるので。

成功画面は予め1枚のスクリーンとして作っておきます。PowerAppsの編集画面左上にある「新しい画面」から「成功」を選ぶとそれらしい画面が生成されます。

ここまででフォームの編集ができるようになりました。
次に考えたいのが、前のデータ残っている場合です。

ここで想定しているSharePointのリストのデータ設計では、ロッカー番号に1対1でレコードがあります。これのレコードを書き換え続けます。したがって、荷物を受け取り済みにしても、前の荷物の情報が残ります。こうしておくと、前の荷物に関するトラブルが生じたときに直前回の情報がすぐに手に入るのでトラブル解決に便利です。
一方で、新しく荷物を預け入れたいのに、編集フォームで前の荷物の情報が出てきてしまうと困ります。誤った情報の登録にもつながります。そこで、SharePointのリストから読み取った情報の一部を消してPower Apps上で表示します。

Receiver_DataCard1の詳細設定>データ>DefaultにBlank関数を入れることで、入力フォームの値が入っていない状態にできます。入力フォームがBlankだとSubmitformが動作しないので、意図しない受取人を設定するミスを予防できます。

受取人はBlank関数を使えばいいのですが、荷主Sender, 伝言messageはこの方法が使えません。Sender, messageは入力必須でない項目なので、値がBlank()でもSubmitformできます。値がBlankのままSharePointのリストに送信された項目は、前の値が更新されずに残ります。受取人Receiverは入力必須なのでSubmitformが動かずこのようにはなりません。そこで、Sender, messageは明示的に空の文字列を与えてやる必要があります。Blank()の代わりに“”と書きます。

荷物を回収する動作画面をつくる

次に、荷物がない場合つまりhasItemが「はい」のときを考えます。荷物を回収する動作画面では、荷物の受取人をユーザーとして想定します。また、想定する動作は荷物を回収するのみです。

荷物を預け入れる動作の画面とほとんど同じように作れます。こういうときはツリービュー>荷物の預け入れ動作の三点ボタンから「画面の複製」を行うと楽です。各アイテムの名前の末尾に_1が付与されて画面ごとに名前が異なるように調整されることに注意して下さい。

ツリービューからhasItem_DataCard1_1のプロパティを開き、詳細設定のDefaultをfalseにします。falseは「いいえ」を意味します。

この画面でユーザーに期待するのは荷物の回収だけです。そこで、既存のデータを書き換えられないようにしておきます。
編集フォームコントロール自体に、動作を編集・新規投稿・ビュー(閲覧のみ)に設定できます。しかし、編集フォームコントロール全体の設定で動作モードをビューに設定してしまうと、SubmitFormでSharePointのリストを書き換える動作も封じられます。そこで、画面に表示されている各入力欄の設定を表示のみに書き換えます。
ツリービューを見るとForm配下の末端にDataCardValueという名前の付いた入力系コントロールがあります。これが入力欄です。これの詳細設定の一番下の方にDisplayModeというプロパティがあります。これをDisplayMode.Viewに設定すると、動作時に表示のみになります。

---

配布の準備

作成したアプリを業務で使えるようにしましょう。

「共有」から公開を行うと、Web リンクに次のようなURLが表示されます。これが作成したアプリへアクセスするためのURLです。
https://apps.powerapps.com/play/example?tenantId=example

今回作成したアプリは、URLからロッカー番号を指定できるようにしました。前述のURLの末尾に&でLockerID=#をつなぎます。#にはロッカー番号を入れます。

例:ロッカー番号51のとき
https://apps.powerapps.com/play/example?tenantId=example&LockerID=51

このURLをQRコードのして印刷し、ロッカーの現場に表示しておけば、利用者はスマホでQRコードを読み込むだけでアプリにアクセスできます。URLからQRコードを作るにはqrqrなどを使います。

---

本アプリの作成を通じて業務の自動化を体験するワークショップを開催する場合の進め方例

1回目
小包、郵便をオフィス内で分配する業務フローを書き出してみる。
業務フローの中で困っていること、面倒なこと、間違いが起こりやすいことを探す。
消費者として使用した宅配ロッカーの経験を基に、宅配ロッカーの業務フローを書き出してみる。
これらを踏まえて、最終的なワークフローを書く。

2回目
SharePointのリストにデータを格納する方法を考える。
まずExcelにデータを入れて、手作業ですべての操作をすることを考える。
どんな列にどんなデータが入ればいいかを考える。
業務フローをカバーできるExcelができたら、これを基にSharePointのリストを作成する。

3回目
SharePointのリストに対して、PowerAppsからデータを操作できるようにする。
PowerAppsの勉強の導入になるので時間をかけて、リード役が画面を見せながら説明する。

4回目
SharePointのリストに対して、Power Automateで連絡のフローを作成する。
「自動化されたクラウドフロー」を「SharePointのアイテムが作成または変更されたとき」トリガーで実行する。

5回目
サービス展開に必要な資料を作成する。
ユーザーへの説明書はもちろん施策の狙いをまとめた資料を作成する。
ユーザーへの説明書はできるだけ具体的でわかりやすくする。ユーザーの支持を得るため。
施策の狙いをまとめた資料は、現場の切なる問題の提示とともにDXのような今時でいい感じの雰囲気をちりばめる。このような活動に肯定的な感触を持ってもらい、今後も自由に活動しやすくするため。