HubSpotとSalesforceの連携で、リードが多すぎる、担当者やステータスが一致しないといった問題を防ぐには、営業に渡すコンタクトの条件と、項目ごとにどちらのシステムの値を正とするかを先に決めます。すべてのコンタクトを送るのではなく、inclusion segment（同期対象のセグメント）で対象を絞り、Salesforceでの作成先と所有者の扱いをそろえるのが基本です。接続後はデータが届いたかだけでなく、担当の営業が連絡できる状態になったかまで見届けます。
HubSpotとSalesforceの連携前に、何を決めるべきか？
HubSpotでマーケティングを担い、Salesforceで営業が商談を管理している場合、両者を接続するだけでは引き継ぎの仕組みは整いません。データを送る条件と、受け取った営業の対応が別々に決められていると、Salesforceにレコードがあっても誰も連絡しない状態が残ります。
連携前にそろえたいのは、次の項目です。
-
どのコンタクトを営業に渡すか
-
Salesforceでリードと取引先責任者のどちらとして作るか
-
各項目をどちらのシステムで管理するか
-
誰が担当者を割り当てるか
-
営業がいつまでに連絡し、対応状況をどこに残すか
マーケティング担当者だけで設定を進めず、Salesforceの管理者と、リードを受け取る営業の責任者も交えて決めます。マーケティング側で「引き継ぎ済み」と扱っていても、営業側で担当者や連絡期限が共有されていなければ、コンタクトへの連絡は始まらないためです。
これから接続する場合は、営業が受け取るときに必要な情報から考える
最初に考えるのは、同期する項目の数ではなく、営業が受け取ったときに何が分かれば連絡できるかです。
例えば、営業に渡した理由、担当者、対応状況をどこで見られるようにするかを整理します。情報がHubSpotにあっても、営業がSalesforceだけを見て対応するなら、営業の判断に必要な項目の対応付けを検討する必要があります。
あわせて、Salesforceでリードを受け取る運用なのか、取引先責任者として扱う運用なのかを営業側に尋ねます。マーケティング側の都合だけで作成先を選ぶと、営業が普段扱わない場所にデータを送ることになるためです。
すでに接続している場合は、設定変更の前に問題を分ける
「同期がおかしい」と一つの問題にまとめず、次のように分けて記録します。
-
送るべきコンタクトがSalesforceにない
-
送る必要のないコンタクトまでSalesforceにある
-
レコードはあるが、担当者が違う
-
項目の値が書き換わる
-
商談が進んでもHubSpotのライフサイクルステージが変わらない
-
同じ会社がHubSpotに複数ある
問題ごとに見る設定が違います。対象、項目、所有者を一度に変更すると、どの変更が結果に影響したのか追いにくくなるため、まず該当するレコードと項目を絞ってから設定を直します。
営業への引き継ぎ自体が曖昧な場合は、HubSpotを使っているのにリードが営業に渡らないのはなぜか｜件数と体制で見分けるも参考になります。
HubSpotとSalesforceの連携設定は、どの順番で進めるべきか？
先に契約と権限を調べ、その後で接続、同期対象、項目の対応付けを設定します。接続できたことと、意図したデータが営業に届くことは別なので、最後にレコード単位で結果を照合します。
Step.1：契約と連携ユーザーの権限を調べる
HubSpotとSalesforceの連携は、Marketing Hub・Sales Hub・Service Hub・Data Hub・Content Hub・Smart CRMのいずれかのProfessionalまたはEnterpriseで利用できます。Marketing Hub Professional以上を使っている場合は、HubSpot側の契約条件を満たしています。
Salesforce側は、APIアクセスのあるエディション、またはSalesforce Professionalが対象です。Group Editionは対象外です。
接続に使うSalesforceのユーザーには、システム管理者であることに加え、API Enabled（APIの利用）、View Setup and Configuration（設定情報の参照）、同期するオブジェクトのModify All（すべてのレコードの変更）などの権限が必要です。Salesforceの管理者に、接続に使うユーザーと同期するオブジェクトを伝え、必要な権限があるか調べてもらいます。
営業担当者が日常的に使う操作に必要な権限と、連携に必要な権限は分けて考えます。接続用ユーザーの権限が足りないと、項目の対応付けを直してもデータを受け渡せないためです。
Step.2：アプリを接続し、設定画面を開く
HubSpotのMarketplace（画面上の英語表記）でSalesforceを検索し、Install（インストール）を選びます。その後、Salesforceにログインして接続します。
接続後は、HubSpotのSettings → Integrations → Connected Apps → Salesforceを開きます。Settingsは設定、Integrationsは連携、Connected Appsは接続済みアプリを指します。
以降の設定は、このSalesforce連携の画面から進めます。すでに接続済みの場合も、インストールし直すのではなく、まず現在の設定内容を記録します。設定を変更する前後で比較できるようにするためです。
Step.3：同期対象とSalesforceでの作成先を選ぶ
inclusion segment（同期対象のセグメント）を選び、HubSpotからSalesforceへ送るコンタクトを絞ります。現在はinclusion segmentと呼ばれていますが、以前のinclusion listという名称や、Create inclusion listという表記が画面に残る場合があります。
続いて、HubSpotのコンタクトをSalesforceで何として作成・更新するかを選びます。
-
Create or update the contact：取引先責任者として作成・更新
-
Create or update the lead：リードとして作成・更新
ここでは、営業が受け取る対象と作成先が、事前に決めた運用に合っているかを見ます。セグメントを選ばない場合はすべてのコンタクトが同期対象になるため、対象を絞る方針なら未選択のまま進めないようにします。
Step.4：項目と所有者の設定を整え、レコード単位で照合する
Field mappings（項目の対応付け）で、HubSpotのプロパティーとSalesforceの項目、同期ルールを見ます。そのうえで、営業が使う項目について、どちらのシステムの値を残すかを設定します。
設定後は、担当者がいるコンタクトと、担当者がいないコンタクトを分けて結果を調べます。所有者は通常の項目と同じようには扱えず、担当者の有無によって新規レコードの所有者が変わるためです。
照合するときは、メールアドレス、Salesforceでのレコードの種類、所有者、対象項目の値を並べます。「同期された」という判定だけで終えず、営業が使える状態かを項目ごとに見ると、修正すべき設定を絞れます。
同期対象は、すべてのコンタクトではなく何を基準に絞るべきか？
基本は、営業に渡す条件を満たしたコンタクトだけをinclusion segmentに入れる方法です。メールアドレスを取得したことと、営業が連絡すべき状態になったことを分けて扱います。
HubSpotとSalesforceの連携では、メールアドレスでHubSpotのコンタクトとSalesforceのリード・取引先責任者を照合します。ただし、照合できるからといって、そのコンタクトを営業に渡すべきだとは限りません。同期対象は、営業の受け取り基準に沿って別に決めます。
営業と引き継ぎ条件を共有できている場合
すでにMQLなどの引き継ぎ基準について営業と認識がそろっているなら、その条件をinclusion segmentに反映します。
例えば、合意済みのMQL条件を満たすコンタクトを対象にする方法や、営業への引き継ぎ可否を管理するプロパティーを用意し、その値で対象を絞る方法が考えられます。これは設定例であり、MQLという名称を使うだけで営業への引き継ぎ条件が整うわけではありません。
セグメントを選ぶ前に、対象に入るコンタクトを見て、営業が受け取る理由を説明できるかを確かめます。「資料を取得したから」という理由だけでは営業が連絡を始めない運用なら、その条件だけで同期対象を設定しない方が運用しやすくなります。
MQLの定義について営業と認識がそろっていない場合
ライフサイクルステージだけで対象を選ぶ前に、「誰に、どの理由で連絡してほしいか」を文章にします。その文章を、HubSpot上で判定できる条件へ置き換えます。
ここで営業と話し合いたいのは、対象になる条件だけではありません。対象から外す条件、担当者の決め方、対応できないときの扱いも含めます。受け取り条件だけを定めても、営業が対応できないリードの管理先が曖昧なままでは、未対応の理由が分からなくなるためです。
インサイドセールスからフィールドセールスへの引き継ぎも含めて整える場合は、インサイドセールスとフィールドセールスの違い｜リードの引き継ぎ基準の決め方を参考に、どの段階で誰が受け取るかをそろえます。
すでにすべてのコンタクトを同期している場合
まず、現在のinclusion segmentの選択状況と、営業が実際に対応しているコンタクトの条件を照らし合わせます。その違いを見て、新たに送る対象を絞る方針を決めます。
このとき、同期対象の設定変更と、Salesforceにある既存レコードの整理は別の作業として扱います。対象を絞る設定だけで、既存レコードの整理まで済んだと判断しないためです。
また、Salesforceには1日あたりのAPI呼び出し上限があり、コンタクト1件の同期で呼び出しが4回に達することがあります。営業が使わないコンタクトまで一律に送ると、営業が受け取る件数だけでなくAPI使用量も増えるため、対象を絞る理由を両面から整理します。
HubSpotのコンタクトは、Salesforceでリードと取引先責任者のどちらとして作成すべきか？
選ぶ基準は、営業がその相手をどのレコードで受け取り、対応を始めるかです。「HubSpotのコンタクトだからSalesforceでも取引先責任者にする」と、名前だけで対応付けないようにします。
同じ人物を扱っていても、HubSpotのコンタクトとSalesforceのリード・取引先責任者では運用上の役割が異なります。マーケティング側の分類よりも、Salesforce側でどの段階から営業が管理するかを基準に選びます。
Salesforceでリードを受け付ける運用の場合
営業がリードとして受け取り、対応後にSalesforceで変換する運用なら、Create or update the lead（リードとして作成・更新）を検討します。
この場合は、HubSpotで会社を自動作成・関連付けする設定を無効にすることが勧められています。Salesforceのリードには取引先がなく、後でリードを取引先責任者に変換すると、HubSpotで会社が重複するためです。
会社の重複は、名称の表記ゆれだけを探しても解消しない場合があります。リードとして同期しているか、HubSpotで会社を自動作成しているか、Salesforceでいつ変換したかを一緒に調べる必要があります。
設定を変更する前には、HubSpotで会社の自動作成・関連付けを利用している運用も洗い出します。重複への対処と、マーケティング側で会社情報をどう扱うかを同時に決めるためです。
Salesforceで取引先責任者として受け取る運用の場合
営業が取引先責任者として扱う前提なら、Create or update the contact（取引先責任者として作成・更新）を検討します。
ただし、会社の重複を避けたいという理由だけで、作成先をリードから取引先責任者へ変えることは控えます。営業がリードを受け取る運用のままなら、作成先の変更によって別の場所に未対応のデータが残るおそれがあるためです。
判断に迷うときは、営業が現在使っているレコードを見ながら、受け取りから対応開始までをたどります。設定名の比較より、営業がどこに対応結果を残すかを基準にすると選びやすくなります。
同じ会社がすでに重複している場合
HubSpotで重複している会社に関連付けられたコンタクトを取り上げ、Salesforce側でリードだった時点の状態と、取引先責任者へ変換した後の状態を調べます。あわせて、HubSpotの会社の自動作成・関連付けの設定を見ます。
その後で、新たな重複を防ぐ設定と、既存の重複を整理する作業を分けて進めます。既存データだけを整理しても、会社を作る条件が同じなら、後のリード変換で同じ問題が起きる可能性があるためです。
重複や表記ゆれの整理は、MAのリードデータの重複・表記ゆれはどう整理するか｜名寄せの手順で扱っています。
項目ごとの同期ルールでは、どちらのシステムの値を正とすべきか？
項目ごとに、誰が内容を判断し、どちらのシステムで更新するかを決めてから同期ルールを選びます。「双方向なら両方にそろう」という理由だけでTwo-wayを選ぶと、残したい値が後の更新で上書きされることがあります。
Field mappingsでは、対応する項目名だけでなく、値の意味と更新を担当する人についても認識をそろえます。名前が似ていても、マーケティングと営業で違う意味に使っている項目は、そのまま対応付けない方が混乱を防げます。
| 同期のルール | 動き | 向いている項目 |
|---|---|---|
| Prefer Salesforce unless blank | Salesforceが空のときだけHubSpotの値を送る。Salesforceの値がHubSpotを上書きする | HubSpotの値を初期情報として使い、その後は営業がSalesforceで管理する項目 |
| Always use Salesforce | HubSpotからは送らない。Salesforceの値がHubSpotを上書きする | Salesforceだけで管理する項目 |
| Two-way | 新しく更新された方の値で上書きする | 両方で同じ意味の値を更新する項目 |
| Don’t sync | 同期しない | 片方だけで使う項目 |
HubSpotで取得した情報を、営業が後から直す場合
HubSpotで取得した情報を初期値として使い、その後は営業の判断を反映した値を残したい項目では、Prefer Salesforce unless blankを検討します。Salesforceが空ならHubSpotの値を送り、Salesforceに値があればそちらを優先するためです。
例えば、マーケティングが取得した情報をもとに営業が内容を補正する運用なら、どの時点からSalesforceの値を残したいかを話し合います。その結果に合わせてルールを選ぶと、「HubSpotの情報で営業の修正が消えた」という行き違いを避けやすくなります。
Salesforceだけで判断・管理する場合
営業がSalesforceで値を決める項目には、Always use Salesforceを検討します。このルールではHubSpotから値を送らないため、HubSpotにある値を初期入力に使いたい項目とは分けて考えます。
Prefer Salesforce unless blankとの違いは、Salesforceが空のときにHubSpotから値を送るかどうかです。Salesforce優先という共通点だけで選ばず、空欄をHubSpotの情報で埋めたいかまで決めます。
また、マーケティングだけが使う分類を営業側の項目に合わせる必要がなければ、Don’t syncも選択肢です。同期項目を増やす前に、営業がその値を読むのか、更新するのかを確かめます。
両方のシステムで更新する場合
Two-wayでは、新しく更新された方の値がもう一方を上書きします。情報の正しさや、営業上の判断の重要性を比較して値を選ぶルールではありません。
そのため、両方のシステムで同じ意味の値を扱い、どちらで更新しても受け入れられる項目に使います。マーケティングの分類と営業の判断が異なるなら、別項目で保持する案も検討します。異なる意味の値を一つの項目で受け渡すと、どちらの値を正とするかは設定だけでは解決できないためです。
一つのHubSpotプロパティーを複数の項目に対応付けている場合
Field mappingsで、一つのHubSpotプロパティーが複数のSalesforce項目に対応していないかを見ます。この対応付けは、値の上書きや意図しない同期、同期ループにつながることがあるため避けます。
対応付けが複数ある場合は、各項目を誰が何に使っているか整理し、送信先を絞ります。項目名が似ているという理由だけで対応付けを残さず、用途が異なるなら別の情報として扱う方が、変更の影響を追いやすくなります。
所有者が合わないときは、どこを調べるべきか？
所有者は、通常の項目とは別に扱う必要があります。所有者の項目は、画面の表示にかかわらず双方向で同期するため、表示上の同期ルールだけを見て「片方向だから変わらない」と判断しないようにします。
また、HubSpotからSalesforceへ所有者が同期されるのは、Salesforceの有効なユーザーと名前・メールアドレスが一致する場合だけです。担当者の名前が画面に表示されているかと、同期の条件を満たしているかは分けて調べます。
HubSpotで担当者を割り当ててから渡す場合
HubSpotのコンタクトの所有者と、対応するSalesforceユーザーの情報を並べて、名前とメールアドレスが一致するか、Salesforceユーザーが有効かを調べます。条件を満たしていなければ、Salesforceの管理者とともに対象ユーザーの情報をそろえます。
あわせて、営業に渡す条件を満たすタイミングと、担当者を割り当てるタイミングを整理します。担当者が付く前にSalesforceの新規レコードが作られると、意図した営業担当者が所有者にならないためです。
担当者の割り当て方法を整える場合は、HubSpotでリードの担当者を自動設定する方法｜ワークフローと連絡期限を参考に、担当者と連絡期限を一緒に考えます。
Salesforceで担当者を割り当てる場合
担当者のいないHubSpotレコードからSalesforceに新規レコードが作られると、連携ユーザーが所有者になります。
Salesforce側で担当者を決める運用なら、連携ユーザーが所有者になっているレコードを受け取り、誰が担当者を割り当てるかを明文化します。連携ユーザーが所有者になったことだけでエラーと判断するのではなく、営業担当者が付くまでの手順と責任者が定められているかを見ます。
一方、HubSpotで担当者を付けて渡すつもりだったなら、連携ユーザーが所有者になっている理由を調べます。新規作成時にHubSpotの所有者が空だったかを、該当コンタクトからたどります。
異動や担当変更の後に合わなくなった場合
HubSpotの所有者とSalesforceの有効なユーザーを再度照合します。担当者の氏名だけでなく、メールアドレスとユーザーが有効かどうかも調べます。
その後、今後どちらのシステムで担当変更を行うかを決めます。所有者は双方向で同期するため、マーケティングと営業が別々の意図で変更すると、担当者の認識が食い違いやすくなります。
ライフサイクルステージとリードステータスは、どう使い分けるべきか？
HubSpotのライフサイクルステージ、HubSpotのリードステータス、SalesforceのLead Status（リードの状況）は、別の項目です。名前や値が似ていても、自動で対応付けられるわけではありません。
ライフサイクルステージは見込み客との関係がどの段階にあるかを、HubSpotのリードステータスは新規・対応中などの対応状況を表します。商談までの進み方と、担当者が今何をしているかを一つの項目にまとめず、用途を分けて考えます。
営業の対応状況をHubSpotでも見たい場合
Salesforceで営業がどの項目に対応状況を残しているかを調べます。その項目をHubSpot側のどのプロパティーに対応付けるか、Field mappingsで見ます。
このとき、項目名だけでなく値の意味も照らし合わせます。例えば、両方に「新規」という値があっても、片方がレコード作成直後、もう片方が営業の未着手を表すなら、その違いを残したまま対応付けると集計や引き継ぎの判断がずれます。
営業の対応状況を知るためにライフサイクルステージを変更するのではなく、まず営業が対応状況を入力する項目を特定します。目的に合う項目を選ぶ方が、後から値の意味を読み解く負担を抑えられます。
Salesforceの商談からライフサイクルステージを進めたい場合
Salesforce連携の設定で、Select what happens in HubSpot when a Salesforce contact’s opportunity stage is updated in Salesforceを見ます。これは、Salesforceの取引先責任者に関係する商談のフェーズが更新されたとき、HubSpotでどう扱うかを選ぶ設定です。
ここでUpdate the contact’s lifecycle stage in HubSpot（HubSpotのコンタクトのライフサイクルステージを更新）を選ぶと、Salesforceの商談フェーズの更新に応じてライフサイクルステージが更新されます。
ただし、Salesforceの取引先責任者がcontact roles（取引先責任者の役割）で商談に結び付いている必要があります。ライフサイクルステージが進まないコンタクトがあれば、次の順番で見ます。
-
HubSpotのコンタクトに対応するSalesforceの取引先責任者を特定する
-
該当商談のcontact rolesに、その取引先責任者が入っているか調べる
-
Salesforce連携のライフサイクルステージ更新設定を見る
-
関連付けや設定を整えた後、商談フェーズ更新時の結果を照合する
商談が存在するだけで、関係するすべてのコンタクトのステージが進むと考えないようにします。商談と人物の関連付けまで見ることで、設定とデータのどちらを直すべきかを判断できます。
測定方法を整理する場合は、HubSpotのライフサイクルステージで商談まで測る｜リードが次の段階に進まない原因とは？も参考になります。
HubSpotのステージ変更でリードを変換したい場合
HubSpotのライフサイクルステージを変更しても、Salesforceのリードは取引先責任者に変換されません。リードの変換はSalesforceで行います。
そのため、営業には「HubSpotの段階が進んだこと」と「Salesforceでリードを変換したこと」を別々に扱ってもらいます。商談の更新に応じたライフサイクルステージの更新を利用する場合も、対象者がSalesforceでどう管理され、商談にどう結び付いているかまでたどる必要があります。
同期結果が想定と違うときは、何から順に調べるべきか？
まず該当するコンタクトを絞り、同期対象、メールアドレス、作成先、項目、所有者の順に見ます。商談に関係する問題なら、最後に取引先責任者と商談の関連付けを調べます。
「全件が同期されない」のか、「特定の人だけ同期結果が想定と違う」のか、「特定の項目だけ値が違う」のかも分けます。接続や権限の問題と、レコードごとの条件の違いを混ぜずに調べるためです。
レコードそのものがSalesforceに見当たらない場合
HubSpotのコンタクトが、選択中のinclusion segmentに入っているかを見ます。次に、メールアドレスと、Salesforce側でリード・取引先責任者のどちらを探しているかを照合します。
その後、Settings → Integrations → Connected Apps → Salesforceで同期エラーを調べます。接続設定全体を変える前に、対象外なのか、探しているレコードの種類が違うのか、同期エラーがあるのかを分けます。
レコードはあるが、一部の値だけ違う場合
Field mappingsで、該当するHubSpotプロパティーとSalesforce項目の対応、同期ルールを見ます。
Salesforceの値を優先する設定なら、HubSpotで値を直すだけでは意図した結果になりません。先にどちらの値を残すべきかを決め、その判断に設定を合わせます。同じ値を何度も入力し直すより、上書きの方向を調べる方が原因を追いやすくなります。
所有者だけが違う場合は、通常の項目の同期ルールではなく、ユーザーの一致条件と新規作成時の担当者の有無を調べます。
対象が増えた後に同期エラーが出た場合
Salesforce連携の設定画面で、直近24時間のAPI使用量と同期エラーを見ます。あわせて、inclusion segmentの条件変更や、同期対象の増加がなかったかを調べます。
API使用量が多いという理由だけで原因を断定せず、エラーの内容と対象レコードを照合します。そのうえで、営業が使わないコンタクトまで対象にしていないかを見直します。対象条件を変えるなら、件数を抑えることだけを目的にせず、営業への引き継ぎ基準に合わせて絞ります。
同期は成功しているのに営業が対応していない場合
Salesforceのレコードで、所有者、営業が受け取った理由、対応状況を見ます。その後、担当者が連絡する期限と、対応できない場合の扱いが営業内で共有されているかを調べます。
この場合、連携設定を変えるだけでは営業の対応は増えません。データを送る作業と、営業が受け取って対応する作業を分け、後者の責任者を決める必要があります。
また、商談までの件数を分析する前には、同期対象や項目の意味が期間によって変わっていないかを整理します。HubSpotのデータを分析に使う前に確かめること｜期間・件数・項目の整え方では、集計前にそろえたい条件を扱っています。
HubSpotのデータから、今日連絡すべきリードを決めるには
LisCoreは、MAに蓄積されたデータを毎日解析し、その日にトスアップする相手を一覧にする自社開発のツールです。2026年11月2日からβ版を提供し、HubSpot Marketing Hubをお使いの企業さまを対象に10社限定で募集しています（募集は2027年3月末まで）。
デモを申し込む →まとめ
HubSpotとSalesforceを連携する際は、アプリの接続よりも、営業に渡す対象とデータの管理方針をそろえることに時間をかけます。設定を進める順番は、次のように整理できます。
-
営業に渡す条件を決め、inclusion segmentで同期対象を絞る
-
営業の受け取り方に合わせて、リードか取引先責任者かを選ぶ
-
項目ごとに正とするシステムを決め、同期ルールを設定する
-
所有者の一致条件と、担当者がいない場合の扱いを整える
-
商談からステージを更新する場合は、contact rolesでの関連付けまで見る
これから連携する場合
接続前に、対象条件、作成先、項目、所有者について営業と認識をそろえます。接続後にレコードを直す作業を増やさないため、営業がどこで受け取り、誰が対応するかまで決めてから設定します。
すでに同期のずれがある場合
問題のあるレコードを取り上げ、対象条件、対応付け、所有者、商談との関連付けを分けて調べます。一つの設定でまとめて解決しようとせず、どの条件で意図と違う結果になったかを追うと、修正範囲を絞れます。
よくある質問
マーケティングの分類はHubSpot、営業の判断はSalesforceに残したいのですが、同じ項目にまとめるべきなのか？
意味が異なるなら、同じ項目にまとめない方が扱いやすくなります。例えば、マーケティング上の関心分類と、営業が判断した対応方針は、別の情報として残す案を検討します。
両者を一つの項目で双方向同期すると、後から更新された値がもう一方を上書きします。まず値の意味と更新する人を整理し、その後で対応付けるかどうかを決めます。
既存顧客のコンタクトも、営業への引き継ぎ対象に入れるべきなのか？
新規リードと同じように営業に対応してほしいかどうかで分けます。既存顧客だから一律に含める、または除外するのではなく、誰が何の目的で受け取るかを決めます。
担当営業がすでにいる相手なら、所有者の扱いも一緒に整理します。同期対象に入れる判断と、新規リードとして営業に連絡を依頼する判断を混同しないためです。
API使用量が多いときは、同期対象を一律に減らすべきなのか？
まずSalesforce連携の設定画面で、直近24時間のAPI使用量と同期エラーを調べます。API使用量だけを理由に対象を減らすと、営業に渡すべきコンタクトまで外すおそれがあります。
対象を絞るなら、まず営業への引き継ぎ条件を満たしていないコンタクトが含まれていないかを見ます。コンタクト1件の同期でAPI呼び出しが4回に達することはありますが、単純な割り算だけで送ってよい件数を判断しないようにします。
設定が多く、何から直すべきか分からない場合は、どこを優先すべきなのか？
営業に渡すべきコンタクトが届いているか、担当者が付いているかを先に調べます。その後、営業の判断に使う項目、商談の更新に応じたステージ更新という順で整理します。
この順番なら、連絡すべき相手に営業が対応できない問題から手を付けられます。分析用の項目を整える作業と、営業の対応を始めるための修正は、優先順位を分けて考えます。
Salesforceの担当者が無効なユーザーになっている場合は、HubSpot側だけを修正すべきなのか？
HubSpot側だけの変更で済ませず、Salesforceの管理者と相談し、有効なユーザーを担当者に決めます。HubSpotから所有者を同期するには、Salesforceの有効なユーザーと名前・メールアドレスが一致する必要があるためです。
両方のシステムで対応する担当者をそろえたうえで、今後の担当変更をどちらで行うかも決めます。所有者は双方向で同期するため、別々の判断で変更しない運用が必要です。
過去のデータをまとめて直す前に、何をそろえるべきなのか？
修正対象、残す値、正とするシステム、現在の同期ルールを整理します。特に、同期対象の変更、項目値の修正、重複の整理は別の作業として記録します。
Salesforce優先の項目をHubSpotだけで修正しても、意図した値が残るとは限りません。先にField mappingsで上書きの方向を調べ、修正後に両方のレコードで何が残るべきかを決めてから進めます。
