正式な記録と届いた成果の間には、イベント選択、ルール実行、要求送達、受信側処理があります。どこが止まっても利用者には「通知が来ない」と見えます。
元レコードを繰り返し更新する前に、変更が対応イベントかを確認します。サンプル、実際の実行、受信結果を分ければ、ルールと下流のどちらを調べるか決められます。
その変更は対象イベントか
スペースメニューからWebhooksを開きます。ルールはイベントを選び、Base単位またはスペース全体を対象にできます。公式ガイドのイベントは四つです。New Recordは新規レコードが作成されBaseへマージされた時、@AI mentionはコメントでAgentが言及された時、Changes requestedは修正が要求された時、Asset uploadedはまだテキストを読めないファイルがアップロードされた時です。
New Recordを既存レコードのあらゆる更新通知と考えないでください。既存項目の変更を契機にしたいなら、利用可能な仕組みを確認します。業務操作、必要イベント、Base範囲、設定済みルールの対応表を残すと、対象外の操作を受信障害と取り違えずに済みます。
サンプルと本番イベントを分ける
Test nowはサンプル入力で直ちに動かせ、ルールがオフでも利用できます。URL、形式、関数を確認する手段ですが、本番操作が対象条件を満たした証拠にはなりません。
サンプルを確認した後、許可された実操作と対応づけます。テストのために正式レコードや送信を勝手に作らず、環境と対象と権限を明確にします。
ルールの最近の履歴を開き、Successの出力やFailedのエラーを確認します。元レコード、時刻、ルール、実イベントの根拠を残し、受信側のリクエストへつなぎます。短い実行履歴を永久の業務証跡と考えないようにします。
次の担当に合わせて動作を選ぶ
Webhookは指定URLへのHTTP POST、Notify agentはAgentのエンドポイントへの同様のリクエストです。署名用secretを設定し、受信側が送信元を確認できます。Run functionは隔離環境で短いJavaScriptを実行し、fetchで外部サービスを呼び出せます。
受信サービスがあるならエンドポイント、署名検証、業務処理を確認します。Agentへ渡すなら、受信後にどんな成果を残すかを決めます。関数は短い変換や呼び出し向けです。リクエストの成功だけを業務完了にしません。
失敗処理や重複排除は受信側でも設計します。有効化したルールだけで一度限りの実行や、マージと外部処理の原子性を保証できるとは扱いません。
関数は短い処理に使う
関数の制限はfetchを含む100–5000ms、fetchは最大10回です。サーバーのファイルや環境変数は読めず、localhost、私有ネットワーク、クラウド基盤宛ての要求は遮断されます。戻り値は記録用で、次の処理を自動起動しません。長い仕事は適切な受信サービスへ渡し、タイムアウトと重複処理もそこで設計します。
四段階で結果を追う
まずレコードが新規作成され、マージされ、選択Baseにあるか。次に実イベントのルール実行があるか。続いて受信側のリクエストと署名確認。最後に通知、タスク、更新先など実際の結果を開いて調べます。
ルール成功後にも非同期処理や業務失敗があり得ます。確認済みの段階と不足を分け、根拠なしに原因を断定しません。
ルールのイベント、範囲、最近のログを読み、指定レコードがマージ済み新規作成か確認してください。Test nowと実イベントを分け、確認できた段階、受信側の不足資料、次の調査を整理します。再送、作成、ルール変更は行いません。
Agentには対応する読み取り手段と権限が必要です。受信ログを読めない場合は、そのサービス担当者が根拠を補います。
再試行すべき時と別工程を調べる時
業務変更が選択イベントを発生させるか確認します。既存レコードの再保存はNew Recordになりません。Test nowは動作設定の確認で、実際の作成・マージの証拠ではありません。
届いた要求は再送前に応答と業務対象を調べます。受信と処理完了は別で、時間切れだけでは未受信と決まりません。元記録、実行、受信対象の関係を残します。
検証結果を保存する
既存の運用Baseを使い、元レコードへの関連、イベント、ルール名、確認時刻、送信根拠、受信記録、業務結果、残課題を残す構成が考えられます。これは設計案であり、表の作成だけでログ収集が始まる機能ではありません。権限を持つツールか担当者が監査可能な変更として保存します。
まず一つのルールを最後まで確認します。段階が見えれば、ルール修正、受信側修正、受理済み処理の待機を根拠を持って選べます。