SETUP & RECOVERY
接続して、1件確認する。
実行スケジュールを停止したまま、自分だけの通知先で始めます。
準備するもの
Googleフォームと回答シートを作成できるGoogleアカウント、Makeアカウント、アプリ接続を許可できるSlackワークスペース。最初は本人専用の非公開チャンネルを使用します。
フォームには必須の選択式category（quote / support / other）と、必須の短文subjectを作ります。実顧客の名前・メール・本文を使わず、架空の件名で試してください。
設定する順序
1. フォームと回答シート
フォームの「回答」から新規スプレッドシートを作成します。A〜C列はタイムスタンプ、category、subject。D〜I列の見出しに順に以下を追加します。
request_id / state / route / notified_at / slack_ts / last_error
メールアドレス収集は無効にし、この順番以外の質問は初回テストでは追加しません。回答タブ名を「フォームの回答 1」にするか、次の4モジュールのシート名を自分のタブ名に変更します。行2以降のD〜I列は最初は空欄にします。
2. 空のシナリオへ取り込む
Makeで新規シナリオを作り、メニューの「Import blueprint」で配布ファイルを選択します。既存の業務シナリオへ上書きしないでください。
3. Google接続とシート
Google Sheetsの各モジュールで自分の接続を作成し、必要なSheets権限を許可します。モジュール1（Search Rows）、2（PROCESSINGのUpdate a Row）、4（SENTのUpdate a Row）、Slack下のエラー経路6（FAILEDのUpdate a Row）の計4か所で、YOUR_SPREADSHEET_IDを回答シートURLの /d/ と /edit の間のIDに変更します。シート名も4か所で合わせます。最初の接続を選ぶと他のGoogleモジュールへ反映される場合がありますが、必ず4か所を確認します。行番号や列のマッピング、RAWの入力方式は維持します。403が出る場合は、Google Sheetsモジュールから接続を作り直し、権限を確認します。
4. Slack接続と通知先
Slackモジュールで自分の接続を作り、テストチャンネルを選びます。Bot接続の場合はチャンネルにBotを追加します。非公開チャンネルを3つ用意し、各チャンネルの詳細→インテグレーション→アプリを追加、からMakeを参加させます。Slackモジュール3の「Channel ID or name」のswitch式にあるQUOTE_CHANNEL_ID、SUPPORT_CHANNEL_ID、REVIEW_CHANNEL_IDを、見積・サポート・未分類のチャンネルIDへそれぞれ置き換えます。IDはSlackのチャンネル詳細に表示されます。検証時は3つとも本人専用にします。
5. Run onceで1件確認
架空のquote回答を送信してから実行します。回答行の受付ID・担当・状態、Slackの通知を照合します。supportとotherも確認してから、必要であれば実行時間を設定します。定期実行は不要なら停止したままで構いません。
振り分けを変える場所
categoryはquote / support / otherの英小文字で一致させます。フォームの選択肢を変える場合、Slackモジュール3の送信先switch式と本文の担当switch式、Google Sheetsモジュール2・4・6のF列のswitch式も合わせます。未知の値は最後の確認担当へ送ります。まずは配布時の条件で3分類を確認してください。
Slack本文の「検証フォーム」は自分のフォームの識別名へ変更します。件名・自由記述は通知せず、受付IDと担当だけを送ります。件名は権限のある回答シートで確認します。
定期実行する場合
本テンプレートはSearch Rowsの定期確認方式です。Formsから届く新しい行と、人が指定したRETRYを同じ検索で扱います。Limitは1なので、待ち行列が増える運用にはそのまま使わず、実行頻度と処理件数を見直してください。
MakeのWatch Changesはセルの手動編集を対象とし、新しい行やAPI・スクリプトによる変更は対象外です。フォーム送信を即時Webhookとして扱えるとはしていません。即時化には別途フォーム送信トリガー等の設計と検証が必要です。公式のトリガー説明
Save後もInactiveのままRun onceで確認します。必要な場合だけ時計アイコンで頻度を決めてActiveへ変更してください。停止はInactiveへ戻します。この配布物の検証シナリオは停止済みです。回答原本を処理するシナリオは1つだけにします。
状態と再試行
| state | 意味と操作 |
|---|---|
| 空欄 | 未処理。次の対象行検索で選ばれます。 |
| PROCESSING | 通知前の保存が済んだ状態。長く残る場合はMake実行履歴とSlackを確認します。自動では再送しません。 |
| SENT | 通知後の記録が完了。次の検索では対象外です。 |
| FAILED | Slackモジュールのエラーを台帳に記録した状態。エラー経路のSkipで処理を終えるため、Make履歴全体がSuccessでも通知成功とは限りません。stateとSlackの両方を確認します。送信済みか不明なら再送せず調査します。 |
| RETRY | 未送信を確認して人が指定する再試行指示。次の実行で同じ受付IDを使います。 |
- Makeの履歴で失敗したモジュールとエラーを確認する。
- Slackで受付IDを検索する。送信済みなら通知IDを記録してSENTへ修正する。
- 送信されていないことを確認できた場合だけ、接続・通知先を修正しstateをRETRYへ変更する。
- Run onceを1回実行し、通知と台帳を再確認する。
送信結果が不明なままRETRYへ変更すると重複通知が起こり得ます。表の更新とSlack送信は一括のトランザクションではありません。
受付IDと原本の扱い
受付IDは初回に回答行番号を保存し、再試行でも保存済みIDを使います。1枚の回答シート内で識別する設計です。原本の並べ替え、途中行の挿入・削除、IDの書き換えは避けてください。閲覧にはフィルタ表示を使います。別シートのIDと混同しないよう、通知にはフォームの識別名も含めます。
同時に複数のシナリオから同じ回答行を処理しないでください。コピー確認では別の回答シートを使い、元のシナリオは停止します。