【簡単設定！】[_THISROW_BEFORE]の使い方

本ブログでは新UI画面で内容をまとめています。

新旧画面への切り替えは、下図を参考に該当アイコンをクリックしてください(^^)

まずはじめに

この記事は、特定のカラム入力値が〇〇になったときだけメールが送信される方法についてまとめています。

この問題を解決するのに役に立つのが[_THISROW_BEFORE]です。

アプリ開発において必須ではありませんが、使いこなせるようになるとかゆいところに手が届くアプリ開発が行えるようになります。

考え方は非常にシンプルなのでTIPSだと思ってご覧ください(^^)

それでは勉強していきましょう！

参照データについて

本記事で作成するBotのイメージは、上図を意識しています。

以下のデータで検証してみました！

連絡事項シート

読者の皆さんは、必要に応じてカラム数を増やしてみてください(^^)

続いてカラムの設定を行います。

今回は[_THISROW_BEFORE]の検証を行いたいので、それ以外のカラム設定は無視します。

ステータスカラムの設定

Automationの発火条件として用意した、ステータスカラムのタイプをenumに変更します。

• 予定
• 対応中
• 完了
• 緊急

上記4つのステータスを今回は用意しました(^^)

ワンポイント！

今回用いる方法は[カラム名] = “〇〇” の形を取るYes/Noで条件を指定します。

そのため、Botの発火条件となるカラムの入力値はenumを推奨(^^)

[_THISROW_BEFORE]の検証

今回はステータスが緊急となった時に関係者にメールを送信する想定で実践してみます。

考えられるパターンは、以下の2パターンです。

• 新規で登録した案件が最初からステータス：緊急である
• 登録していた案件の進捗が変わり、あとからステータス：緊急になる

それぞれのパターンで、どういうAutomationを設定すればいいかを解説します。

最初からステータスが緊急として登録されるパターン

パターン1の考え方は非常にシンプルです。

新規データを追加、かつそのステータスが緊急

この条件を満たす場合を設定すればOKです。

パターン1の設定

Addsを選択し、Conditionに[ステータス] = “緊急” と入力

上記設定でパターン1については作成完了です！

ただ問題はパターン2・・

Updatesだけでは、データの編集があったらそれがトリガーとなってしまい、データの更新があるたびにメールが送信されてしまいます。

この理想を叶えるのが[_THISROW_BEFORE]と[_THISROW_AFTER]です！

考え方としては、以下の手順になります。

あとからステータスが緊急に更新されるパターン

Event typeのUpdatesを選択

想定のケースは、登録してあるデータを更新するなので、Updates を選択します。

Conditionに関数を入力

[_THISROW_BEFORE].[ステータス]<>[_THISROW_AFTER].[ステータス]

これでステータスカラムが編集前と編集後で変わったらの制限を付けることが可能

この関数を入力することで、他のカラムが編集されてもAutomationは発火しません。（トリガーはステータスカラムのみ）

ただし、この条件ではステータスカラムを更新したらAutomationが発火してしまうので、更に条件を追加します。

Conditionに更に条件を追加

AND([_THISROW_BEFORE].[ステータス] <> [_THISROW_AFTER].[ステータス], [ステータス] = “緊急”)

AND()関数を用いることで、ステータスカラムを編集、かつその値が緊急だったらと、更に条件を指定することが可能です。

上記Botを2つ作成すれば、想定される2パターンの緊急案件（新規登録と更新）についてカバーする事が可能です(^^)

まとめ

以上、使用すればかゆいところに手が届く[_THISROW_BEFORE]と[_THISROW_AFTER]についての記事でした。

今回ご紹介したTIPSは、応用すれば色々なユースケースで効果があるのでぜひ覚えておきましょう(^^)

記事内容について何かありましたらページ下にあるコメント欄からコメントをお願いします。

わかりにくかった部分や間違った情報などご指摘いただけると嬉しいです！

勉強お疲れさまでした(^^)

他にもAutomationの機能を紹介した記事があります