前回

前回はPower AutomateのメニューにあるPeak codeの紹介と、トリガー・アクションの入力・出力をどうやって取り出すかを紹介しました。

今回はもうひとつの「Settings」について、トリガー・アクションでそれぞれ代表的と思われるものを紹介します。念のため、Settingsには↓ここからアクセスします。

Split-On (トリガーのみ)

トリガーにしかない設定です。

Split-Onはトリガーしたときのアイテムsを分割してFlow実行してくれる機能です。

例えばSharePoint listのクイック編集でアイテム作成した場合、Split-On：OFFだと、トリガーは作成されたアイテムsで発生するので、配列を対象に処理することになります。

Split-Onを有効にすると、トリガーしたときの配列をバラバラにして、個別にFlowを実行してくれます。このため、トリガー以降の処理を簡単にすることができます。

もともとPower Automateの旧ライセンス形態では、Flowの実行回数に上限があったため、この設定をOffにすることで実行回数が節約できたんだろうと予想されます。

Concurrency control

Apply to eachなど並列実行できるアクションに関する、並列化の多重度の設定です。

最低は1、最大は50。1の場合には直列に実行されます。

この並列化の多重度、万能なように思えますが、並列化の多重度を上げると、処理順がバラバラになったり、ループの中で依存関係のあるようなアクション(たとえばUpdate variableやAppend to array variableなど)がある場合には十分に恩恵が得られない場合があるので、利用には注意が必要です。ただし、単純なループ処理では劇的に実行速度が改善されるため、処理の内容に応じて設定してみてください。

※並列実行の多重度の恩恵を最大限活用するための方法として、Pieterの方法が有効です。

Secure Inputs/Outputs

アクション/トリガーのInput/Outputを実行履歴に表示しないというものです。

有効にすると、入力をセキュアにする (設定をONにする)と、ほかのアクションでその入力を参照場合でも、履歴上で非表示になります。もちろん、セキュアな入力値を加工したとしても、履歴上では隠蔽されます。

Flowの編集権限は持っていても、履歴に表示されないので、用途としては個人の位置情報を特定できるような入力の隠蔽、あるいはAPI実行時のAPIKeyを含む入力の隠蔽かなと思います。

Tracked Properties

アクションに追加できる追加のプロパティです。ほかのアクションから参照可能 actions('action name')?['trackedProperties'] の書式でデータを取り出します。

Tracked Propertiesはjson形式のデータとして扱われるので、指定する際にはKey : Valueのペアを設定します。

また、Valueは、""ダブルクォーテーションでくくり、関数を使う場合には@(アットマーク)から始める必要があります。

さらに自分自身の入力も、Tracked Propertiesに含めることができます。この場合には前回のブログで紹介した action()?['inputs'] を利用します。自分自身をTracked Propertiesに含めることができるので、これで自分自身のコピーを生成し、通常エラーになるような自己参照した処理も可能になります。

その他の利用例は以下をご覧ください。1アクションで、すべてのフォーマットで時間を定義しています。

Tonight's #FlowNinja hack is an idea I had previously: "how to build MomentJS" in @MicrosoftFlow

The nice part of this is the block itself is copy and paste, and the "input" is on the front of the compose action

So, if I squint a bit - this is a way to write inline functions. pic.twitter.com/zD7Do7Gsg9
— John Liu 劉 (@johnnliu) January 31, 2019

Trigger Conditions

Docsだと全然情報ないのですが、各トリガー(Flowの開始部分)に追加で設定できる発動条件です。

トリガーの[・・・]をクリックして表示されるメニューでSettingsを選ぶと表示されます。

ここには、もともとのトリガーの条件とは別に、トリガーしたときのアイテムや各種データをもとに、さらに発動条件を指定することができます。例えば、SharePointのアイテム作成トリガーで、特定のステータス(選択肢フィールドの値)の場合だったら～とか、反復実行で1分おきに設定するのだけど、発動は日中だけにしたいとか。そういった、もとのトリガーだけではカバーしきれないようなカスタムの発動条件が定義できます。

Trigger Conditionsを使わない場合、トリガーの次のステップでIFやSWITCH等の分岐条件を入れるかと思います。Falseなら実行終了とか。そういった「発動はさせるけど、すぐ条件で終わらせることがある」ようなFlowに対して、Trigger Conditionsは有効に働きます。

何がうれしい？

単純にはトリガー回数を減らせるので、実行履歴が見やすくなります。あとは誤って深夜とかに発動してPush通知飛んじゃうみたいなことも避けれるかもしれません。

ただ、多少は数式を書かないといけないので、そこだけはトレードオフです。

何に使える？

すぐ思いついたのは以下のパターンです。

SharePointリスト/ライブラリで、更新のみ検出する (標準では作成と更新どちらも発動する)
リストの特定のステータスでのみ対象とする (これも作成・更新で後ろでIFしたりする)
反復のスケジュール実行で、実行のウィンドウを指定する (繰り返しを1日おきで、時間指定でもいいけど短いインターバルだと結構大変)

Trigger Conditionsの設定

簡単にいくつかのパターンでTrigger Conditionsの設定方法を見てみます。

1. トリガーしたときのデータに応じた条件

例として、SharePointの選択肢フィールドの値に応じた処理を考えてみます。データに応じた処理を行う場合、基本的には triggerBody() に連なるデータを参照して、条件を書きます。

最初はどんな式を書けばいいのか、どんなデータを受信しているかわからないと思いますので、すごく短い、ただtriggerBody()をComposeするだけのFlowを作ってテストします。

これで得られる結果をもとにして、例えば"Title"のデータを使いたいなら

triggerBody()?['Title']

を利用します。

選択肢フィールドであるStatus は階層的になっているので、その値を使うときは triggerBody()?['Status']?['Value'] になります。

Trigger Conditionsで必須なのは条件式、つまり論理演算です。公式のドキュメントが一番見やすいのでこちらをご覧ください。

あとはお約束事ですが、Trigger Conditionsの式を書くときは先頭に @ をつけます。

これらを踏まえて、『Status列の値が"Closed"の場合』 というTrigger Conditionsは

@equals(triggerBody()?['Status']?['Value'],'Closed')

このように書けます。

2. データ以外の情報を利用する場合

あまり思いつきませんが、指定した時間(hour)で高頻度でFlowを実行させたい場合(7:00~8:00の間に5分間隔とか)には、

utcNow() :　トリガーした時間 (UTC)
formatDateTime() : utcNow()から時間(hour)だけを取り出すために利用
int() : formatDateTimeの結果のStringを整数に変換

これらの関数を組み合わせていきます。

実際に一日ONにしてみましたが、指定時間の間だけ、5分間隔で実行されていました。

裏側まとめ

普段あまり除かない、Power Automateの裏側を見てきました。基本的には、ここらへんはディープなのであまり触らなくてもよいと思いますが、パフォーマンス改善の一つの切り口だったり、個人に紐づく情報の隠蔽だったり、あるいは通常の方法だと1つ変数を増やさないといけないようなケースのワークアラウンドとして、これらを知っておくと幅が広がるかなと思います。