Salesforceと面談予約を連携する前に、予約情報の保存先、既存レコードとの照合方法、更新の優先順位、変更・キャンセル時の処理、連携エラーの確認担当を決めましょう。予約が確定してもSalesforceへの記録だけが失敗する場合があるため、面談の状態と連携の状態を分けて管理する設計が必要です。
この記事は、候補者や顧客をSalesforceで管理し、面談予約の転記を減らしたい運用担当者・管理者向けです。導入前の打ち合わせで使える項目表と確認手順をまとめます。以下の項目名や運用例は設計例であり、waaq Linkの標準項目・標準動作を示すものではありません。
面談予約はSalesforceのどこに記録するか
最初に、一つのレコードが何を表すかを決めます。候補者本人、応募案件、面談予約はそれぞれ別の管理単位です。同じ候補者が複数の案件で面談する場合、候補者のレコードに「次回面談日」だけを上書きすると、どの案件の日程なのか分からなくなります。
現在使っているリード・取引先責任者などの標準オブジェクトと、候補者・応募管理用のカスタムオブジェクトを確認し、予約履歴をどこに持たせるかを決めましょう。既存オブジェクトの項目で足りるか、活動や関連レコードとして履歴を分けるかは、必要な一覧・集計と既存のデータ構造から判断します。
設計例として、候補者と応募案件を既存レコードで管理し、各面談予約を案件に関連付ける構成が考えられます。この場合、候補者一人に複数の予約があっても、予約ごとの変更履歴を追いやすくなります。
項目マッピング表に何を書けばよいか
項目マッピングは、予約側のどの情報をSalesforceのどこへ記録するかを定めた対応表です。項目名だけでなく、型、必須条件、更新できる側、未入力時の扱いまで記載します。
| 情報 | 対応表に記載する内容 | 確認する点 |
|---|---|---|
| 予約ID | 予約を一意に識別するキーと保存先 | 再送時も同じ予約として扱えるか |
| 候補者・案件のID | 関連付け先のオブジェクトとレコードID | 同じ人の別案件を区別できるか |
| 開始・終了日時 | 日時の型、タイムゾーン、表示方法 | 利用者の画面で時刻が一致するか |
| 面談担当者 | 予約側の担当者とSalesforceユーザーの対応 | 退職・異動・代行時の扱いは何か |
| 面談状態 | 確定・変更・キャンセルなどの対応値 | 選択肢の不一致を検出できるか |
| フォーム回答 | 保存が必要な回答と項目の型・長さ | 既存の値を上書きしてよいか |
| 連携管理情報 | 処理状態、最終成功日時、エラーの確認先 | 未反映の予約を発見できるか |
実装担当者には、画面上の表示名と項目API名を併記した表を渡します。空欄は「既存値を維持する」のか「値を消す」のかを区別し、フォームで尋ねなかった情報が消えないようにします。
面談担当者とSalesforceレコードの所有者も、同じとは限りません。代行者が面談するたびに候補者の継続担当まで変更する必要があるかを確認し、それぞれの役割を分けて設計します。
候補者の重複と予約の二重登録はどう防ぐか
候補者の照合と、予約の重複判定は分けます。既存レコードのIDを安全に引き継げる導線では、それを照合に使う設計を検討します。IDがない場合は、新規登録する条件と、既存候補が複数見つかったときの確認担当を決めます。氏名やメールアドレスだけで、無条件に同一人物として統合する運用は避けましょう。
予約については、同じ予約IDの通知が再び届いても新しい予約レコードを作らない処理が必要です。Salesforceには、外部IDを使ってレコードを作成または更新するUpsertの仕組みがあります。利用する連携方式がこれに対応するか、対象項目で一意性を確保できるかを確認します。
ただし、Upsertを使うだけで通知メールなどの二重実行まで防げるとは限りません。保存後に動くフローや通知も、再送時にどこまで実行するかを確認します。Salesforceの公式学習資料でも、同じ要求を繰り返し受けても安全に処理できる設計と、重複の確認が説明されています。
どちらの情報を正しい値として扱うか
予約ツールとSalesforceの両方で同じ項目を編集できる場合、項目ごとに正本を決めます。正本とは、値が食い違った際に優先する情報の保存先です。
たとえば、面談日時は予約側、候補者の継続担当はSalesforce側を正本にする設計が考えられます。Salesforce側で面談日時を手修正する運用があるなら、予約側へ反映する方法と、反映が終わるまでの表示を決めます。単純に最後に届いた値で上書きすると、遅れて届いた通知で古い日時に戻るおそれがあります。
そのため、変更の発生時刻や版番号など、更新順を判断する情報を使えるか確認しましょう。利用する方式で順序を判定できない場合は、処理時に予約側の最新状態を再確認するなど、古い情報を反映させない方法を検討します。
予約変更・キャンセル・面談実施をどう区別するか
予約の確定は、面談を実施したことや選考が進んだことを意味しません。選考ステータスや商談フェーズを変更する場合は、予約情報とは別の業務ルールとして判断します。
- 日時変更：同じ予約を更新するのか、旧予約をキャンセルして再予約するのかを決める
- キャンセル：対象予約をキャンセル状態にし、必要な履歴を残す
- 再予約：別の予約IDになる場合は、旧予約との関係を記録する
- 面談実施：担当者の確認など、実施済みと判断する根拠を決める
- 連絡なしの不参加：開始時刻を過ぎただけで自動判定せず、確認手順を決める
カレンダーの予定、候補者への通知、Salesforceの記録は、変更の影響をそれぞれ受けます。誰がどの画面で変更し、どこまで反映されれば対応完了なのかを一つの手順にまとめましょう。
連携に失敗した予約はどう復旧するか
面談状態が「確定」で、連携状態が「失敗」という組み合わせを扱えるようにします。Salesforceへの書き込み失敗を、候補者の予約失敗やキャンセルと同じにしない設計です。
エラーの種類によって次の対応を分けます。以下は運用設計の例です。
- 一時的な通信障害：既に保存された可能性を確認し、重複を防げる方法で再試行する
- 必須項目不足・選択肢の不一致：入力値や対応表を修正してから再処理する
- 権限不足・認証エラー：管理者が原因を確認し、復旧後に未反映分を照合する
- 繰り返し失敗：再試行の上限を設け、担当者が確認する一覧へ移す
エラー記録には、対象予約ID、発生時刻、失敗箇所、再試行状況を残します。候補者の詳細な回答や認証情報をそのまま記録せず、調査に必要な情報と閲覧者を絞ります。再試行時に候補者への確定通知まで再送されないかも確認しましょう。
運用開始前に試すチェックリスト
本番の候補者データを使わず、テスト用のデータで次の動作を確認します。
- 新規候補者と既存候補者を、それぞれ正しい保存先へ記録できる
- 同じ候補者の別案件・別面談が混ざらない
- 同じ予約通知を再処理してもレコードや通知が増えない
- 日時変更後に古い通知が届いても、最新の日時を保てる
- キャンセル・再予約が正しく関連付けられる
- 項目エラーや通信障害を検知し、担当者が復旧を確認できる
- 予約側の一覧とSalesforceの記録を照合して、未反映を発見できる
waaq LinkのSalesforce連携を検討する際に
waaq Linkの公式機能案内では、標準オブジェクトのリード・取引先責任者・商談と、カスタムオブジェクトへの日程調整結果の記録が案内されています。既存オブジェクトへ確定日程を追加する連携についても紹介されています。
自社の項目対応、変更・キャンセル時の更新、重複判定、再試行まで対応するかは、個別の要件として確認が必要です。保存先と項目マッピング表、例外の一覧を用意すると、設定で対応する範囲と追加設計が必要な範囲を具体的に相談できます。
フォームから日程調整へ進む連携全体を確認したい方は、API連携による商談予約・面接調整の解説もご覧ください。自社のSalesforce構成に合う方法を検討する際は、waaq Linkの機能と導入相談の案内をご確認ください。
