トリガーとイベントソース

実行の開始方法と、自動実行に必要な準備を確認します。

各実行は 1 つのトリガーから始まります。フローに入口が複数あっても、1 回の実行で同時にすべてを開始することはありません。

入口の種類

トリガー	開始のきっかけ
Start	宣言済みの入力を渡す明示的な呼び出し。
Webhook	受け付けられた HTTP リクエスト。
Schedule	予定時刻の到来。
Flow Error	指定した上流フローでの、対象となる本番実行の失敗。
アプリのイベント	Gmail の新着メールや Slack のメンションなど、カタログから選ぶ具体的なイベント。

ドラフトテストではトリガーをシミュレーションできます。本番の自動実行には、公開の成功とフローの有効化が必要です。

トリガーのタブは、組み込みの入口とアプリのイベントを分けて表示します。アプリと具体的なイベントをカタログから選ぶと、その定義が設定フィールドと出力を提供します。アプリのトリガーを参照してください。設定は実行の作成前に決まり、その実行内で生成される出力は読めません。

選んだ入口に応じて、Connection、イベントソース、コールバック検証、アプリ側の権限を設定します。保存済みグラフが有効でも、これらの外部条件が整っているとは限りません。

一部のイベントでは、アプリ、ワークスペース、アカウント単位のソースを共有します。一致するフローごとに個別に配信し、現在の公開版と認可を確認します。1 つの利用フローを無効にしても、他のフローの購読は削除されません。

Connector バックエンドはアプリのプロトコル検証を、Open Flow は実行の受付と配信進捗の永続化を担当します。コールバックを受信しただけでは、実行が受け付けられたとはいえません。

同じイベントに固定の識別子を使うことで、受け付け済みイベントの再試行が別の通常実行を作るのを防ぎます。新しい業務イベントは新しい実行を開始できます。スケジューリング、重複排除、ライフサイクルの調整はデプロイ先が担当します。