Airtableの在庫が発注対象になったらSlackへ通知する

例外・確認の分岐

• Airtable 取得 から分岐

  1. 手動実行で指定されたレコードIDの1件を取得
  2. Airtable側の「通知対象」が真かを単一のequalsルールで判定
  3. 対象外なら終了

  Airtable側で「通知対象」と通知エピソードIDを計算し、対象レコードIDを1件ずつWebhookへ渡せることを実機確認できた場合だけ自動化します。確認できない場合は、対象レコードIDを指定する手動実行にします。

• 条件で分岐 から分岐

  1. 通知エピソードIDと通知済み状態を照合
  2. 並行実行時は双方が未通知と判断する可能性を確認
  3. 自動運用前は担当者がSlackとAirtableを照合

  事前照合と出力後記録だけでは、並行実行時に重複する可能性があります。一意キーの処理中状態を原子的に確保できる台帳、出力先の一意制約・upsert、または同時実行数1を実機確認できた場合だけ自動運用し、それまでは重複の可能性を前提に担当者が出力先を照合します。

• Slack 送信 から分岐

  1. API失敗時は実行失敗として停止
  2. 自動再試行は前提にしない
  3. 結果不明時はSlackとAirtableの通知済み状態を照合して担当者が手動で再実行

  API失敗時は実行失敗として停止します。自動再試行は前提にせず、結果不明時は出力先と台帳を照合してから担当者が手動で再実行します。

再実行や重複防止の扱いは、上の『例外・確認の分岐』に記載しています。