見出し画像

PowerAutomateでOutlookの招待に自動応答する(作成編)

みなさんこんにちは。

以前公開した検討編を元に、実際に作成したフローをご紹介します。

フローの作成

「自動化したクラウドフロー」で、「新しいイベントが作成されたとき」をトリガーとします。
予定表IDは自身がメインで使っている予定表を選択します。

配列変数の作成

「変数を初期化する」のアクションを追加します。
(名前が絶望的に分かりにくいですが、変数を定義するアクションです。)

ちなみにアクションの名前は変更できます。

種類を「アレイ」(配列の意)とし、お好きな名前を設定してください。
後々招待を承認するかの判定に使用するので、judgeという名前にしました。

※変数とは、配列とは、という話はここでは割愛します。わからない方は調べてからお読みいただいた方がいいかもしれません。

マイプロフィールの取得

「マイ プロフィールの取得」アクションを追加します。
これは細かい設定不要で、自分のアカウントの属性値を引っ張ってきてくれます。
イベントの作成者が自分かどうかの判定に使用します。

条件分岐1

本題の自動応答の前に、条件分岐を使ってパターン分けを行います。
若干本題と関係ない部分も含まれますので、この辺りはお好みでカスタマイズしてみてください。

「条件」のコントロールを追加します。
自動承諾に進む必要がないパターンを除外していきます。

1番目の条件は”自分が作成したイベントかどうか”です。
自分が作成したイベントであれば当然承認のプロセスは必要ありません。
トリガーイベントの開催者と、先ほど取得したマイプロフィールのメールアドレスが一致するか判定します。

2番目の条件は”終日イベントかどうか”です。
終日イベントが招待で来ることはレアケースのため、自身で内容を確認する必要があります。

これらを「または」で繋ぎ、「はい」の場合は「終了」コントロールでフローを終了します。

条件分岐2

分岐1の「いいえ」の場合にさらに条件分岐を追加します。

1番目の条件は”繰り返し予定かどうか”です。
定期的な予定が入った場合、自動承諾はしたくないので除外します。

2番目の条件は”自分が必須出席者かどうか”です。
イベントでは必須出席者と任意出席者が設定できます。任意出席者の場合は自分で判断したいので自動承諾から除外します。

3番目、4番目の条件は”既に応答しているか”の判定です。
「新しいイベントが作成されたとき」トリガーはフローが起動するまで最大5分程度かかります。場合によってはその間に手で応答している可能性があるのです。
そこでトリガーイベントの「応答の種類」がtentativelyAccepted(仮承諾)、accepted(承諾)であったら、応答済みとして除外します。
なお、辞退の場合はカレンダーから自動的に消えるので含めません。

分岐1と同様「はい」の場合は終了、「いいえ」の場合は以降の処理に続きます。
※「イベントの更新」については次項で説明

アラームの更新

私はここでイベントのアラーム(通知時間)を変更するために、「イベントの更新」アクションを入れています。

Outlookの仕様で、相手が作成したイベントの場合こちらの既定のアラーム設定が適用されないことがあります。
イベントによってアラームの時間が異なるのは気持ち悪いので、一律4分前に通知させるように変更しています。

ポイントは開始・終了時刻と、各属性の設定値です。

「開始・終了時刻」には、addhours関数を使用してトリガーイベントの開始・終了時刻に+9時間しています。
これはPowerAutomateの仕様で、時間を取得した際に強制的にUTCに変換されてしまうことへの対策です。
例えば、元のイベントの開始時刻が日本標準時10時だったとすると、フロー上では1時になってしまう、ということです。
それをそのまま書き戻すと元の時間から9時間ずれてしまいます。そこで関数を使用して+9時間しているわけです。
ここは説明すると別途記事にするくらいのボリュームになりますので、一旦そういうものだと思っておいてください。

各項目に対応する属性値を全て入れている理由は、更新する際に誤った値に更新されてしまうことを防ぐためです。
当初必須項目だけ入れておいたところ、非公開のステータスが勝手に公開に変更され、みんなに見えてしまうという事故が発生しました。
そのため設定できる項目は全てトリガーイベントから引き継ぐことをオススメします。

イベントの取得

本題に戻りまして、自動応答の判定に使用するカレンダーイベントを取得します。
「イベントのカレンダービューの取得」を使用します。

ここでいう開始時刻と終了時刻は、取得する範囲の意味になります。
自動応答の判定には丸1日分の予定があれば十分かと思うので、formatDateTime関数を使用してトリガーイベントの日時を利用してイベントの取得範囲を設定します。

フォーマット'yyyy-MM-ddTxx:xx:xx'を使用して日時を設定します。
開始時刻はトリガーイベント開始日時の00:00:00、終了時刻はトリガーイベント終了日時の23:59:59とします。
これで日付はトリガーイベントから取得した値、時間は直接指定した値で設定できます。

結果判定のループ処理

いよいよ検討編の自動応答ロジックを組みます。
Apply to eachを利用して、前項で取得したイベントに対しループ処理を行います。

入力値は個別に項目を指定してもよいですが、「value」が便利です。

条件分岐3

"新規予定の開始時刻≧既存予定の開始時刻"の判定を行います。

分かりにくいですが、左辺に既存のイベント、右辺に新規作成されたイベントの値が入っています。

条件分岐4

「はい」の場合は、”新規予定の開始時刻≧既存予定の終了時刻”の判定を行います。

「または」で条件に追加している項目について説明します。

2番目の条件はループ処理の中で比較しているイベントが同一のイベントであるか、を判断するものです。一意の値であるIDを比較しています。
どういうことかと言いますと、実は前段のイベントの取得時にトリガーイベントも一緒に取得されてしまうのです。
同一のイベント同士を比較したら必ず自動応答NGになってしまうため、強制的にOK判定させる必要があります。

3番目の条件は"既存のイベントが終日イベントかどうか"の判定です。
終日イベントがあると同じく必ずNGになってしまうため、強制的にOK判定します。
(とはいえ、遡っていただくと分かりますが最初に終日イベントは除外しているので念の為に入れているだけです)

判定OKになったら、「配列変数に追加」アクションを使用して、作成済みの配列judgeにOKの値を格納します。NGの場合はNGを格納します。

条件分岐5

さて条件分岐3に戻り、「いいえ」の場合の方を作成します。
”新規予定の終了時刻≦既存予定の開始時刻”を判定します。

同様にOK,NGの値を変数に格納します。

ループ処理部分はこれで完成です。

自動応答の判定

既存イベントとトリガーイベントとの重複判定が終わりました。
配列judgeには複数のOKまたはNG値が格納されています。
以降で"1つでもNGが存在するか"を判定します。

アレイのフィルター処理

「アレイのフィルター処理」アクションを使用して、NGの値だけを抽出します。
抽出した結果を再度配列judgeに書き戻します。
これにより配列judgeの中身は1つ以上のNG値、またはnullのいずれかになります。

条件分岐6

empty関数を使用して、配列judgeがnullであるか判定します。

nullである=NGが一つもない
となりますので、イベント招待に自動承諾します。

「イベント招待の応答」アクションを使用して相手に「同意」の結果を返します。

イベントIDにはトリガーイベントのIDを指定します。
コメントは返信されるメールの本文に記載されるものですが、ここはお好みでOKです。

「いいえ」の方はこのまま終了します。

なぜこんなにややこしい処理になっているかというと、イベント招待への返信を1回だけにしたいからです。

OK,NGがいくつあったとしても、最終的に「イベント招待の応答」を実行するのは1イベントにつき1回だけにする必要があります。
そこで応答の判定には値がnullかどうか、を使用しているのです。

まとめ

フローの全体像はこのようになります。

今回は極力コーディングしないことをテーマに作成してみましたが、いかがでしたでしょうか。
関数を駆使すればもう少しシンプルに作成できると思いますが、それではせっかくのローコードツールの意味がなくなってしまいます。
GUIベースでも工夫次第である程度の処理はできる、というところがPowerAutomateの面白さだと思います。

長くなりましたが以上となります。
ご覧いただきありがとうございました。

この記事が気に入ったらサポートをしてみませんか?