Database trigger event（データベーストリガーイベント）

概要

特定のデータベースの変更が発生したとき、サーバーサイドで実行されるイベントです。変更の方法がどうであれ（ワークフロー／API 呼び出し／手動編集など）、発動します。

Database trigger events は、バックエンドワークフローエディタで定義されます。指定したタイプのデータ（Thing）が変更されたとき、その変更を監視して “Only when…” 条件が真であればワークフローが実行されます。

• Thing（データタイプ）を設定して、どのデータ変更を監視するか指定します。
• “Only when…” フィールドで、どのような変更のときに発火させるかの条件を設定します。

「Thing before change」と「Thing now」

このイベントでは、次の２つのデータソースが利用可能になります。

• Thing before change — 変更前のデータ状態
• Thing now — 変更後のデータ状態

これらは、“Only when…” の条件や、イベント発生後のアクションの中で参照できます。

Created / Deleted（作成・削除されたとき）

変更が「作成」「削除」の場合もトリガーされます。

• Created：Thing が新しく作られたとき。変更前（Thing before change）は空の値になります。
• Deleted：Thing が削除されたとき。変更後（Thing now）は空の値になります。

注意事項

この種のイベントを使う際の注意点は以下のとおりです。

• 一つのワークフロー内で複数回データを変更しても、トリガーは1回だけ発火
  → Thing before change は最初の状態、Thing now は最後の状態を反映します。
• プライバシールール（Privacy rules）の扱い
  → Database trigger イベントは管理者権限で実行され、プライバシールールは適用されません。検索も current user の権限ではなく、すべてのデータにアクセスされます。
• トリガーから別のトリガーを直接呼び出せない
  → 例えばワークフロー内でデータが変わると、その変化で他のトリガーイベントが起動することはありません。もしそのようなことをしたければ、トリガーイベントの中でカスタムイベントか API ワークフローをスケジュールするなどの方法を使います。
• データソースの制限
  → “Only when…” の条件では Thing now と Thing before change の２つしか使えず、通常の (他のワークフローで使うような) 全データソースが使えるわけではありません。アクション内ではそれ以外のデータソースも使えるようになります。
• ワークロード（Workload）への影響
  → トリガーが頻繁に発生するような変更なら負荷が大きくなります。条件を厳しくして、必要なときだけ動かすように設計することが重要です。

その他設定

• Event name（イベント名）：ワークフローにわかりやすい名前をつけます。後でこのトリガーイベントを識別するために使われます。
• Type of thing（対象の Thing の種類）：どのデータタイプ（Thing）を監視するかを指定します。
• Timezone selection（タイムゾーンの選択）：静的または動的な代替タイムゾーンを設定して、バックエンドトリガーのタイムゾーンをオーバーライドできます。アプリの一般設定で “Enable timezone override controls” を有効にしておく必要があります。