重要な制限事項

機能面における制限事項

削除データは連携しません

連携元のレコードを削除した場合でも、自動的に連携先のデータを削除することはありません。手動で連携先のデータを削除する必要があります。
リードデータを手動マージした場合も同様に、連携先でも同様にマージや削除を行う必要があります。

SMP の来場取り消しは連携しません

SMP における来場の取り消しは来場データの削除に相当するため、連携によって反映させることができません。一度「来場済み」として連携された来場履歴を取り消した場合は、手動で SFDC から削除等行う必要があります。

連携設定後に追加された項目は連携対象に含まれません

連携設定後に追加・変更された SMP または SFDC の追加項目、カスタム項目を連携対象に含める場合は、項目マッピングを追加する必要があります。

項目のタイプ別の注意事項

  • SMP におけるファイル型、画像型の項目は連携サポート対象外です

  • SMP における数値型項目では10進数で表記するには大きい数や小さい数が指数表現として出力される場合がありますが、通常表記に変換するフィルターはありません

ご利用にあたっての注意事項

SFDC リードが 取引先責任者に昇格(商談化)する際の注意事項

一般的に SFDC では、リードは「取引の開始」処理によって、取引先および取引先責任者に昇格します。昇格後、リード情報は取引先または取引先責任者に引き継がれ、元のリードは参照できなくなります。
SFDC におけるリードと取引先責任者は別オブジェクトであるため、それぞれに対応したオブジェクトマッピングを設定する必要があります。
また、連携のために追加した項目は、昇格時に引き継がれるようにする必要がある場合があります。たとえば、リードにカスタム項目として「SMP_ID」を設定して SMP上のリードIDを保持している場合、取引先責任者にも同様のカスタム項目を設定し、昇格時に SMP_ID を引き継いで、引き続き取引先責任者と SMP リードが連携されるようにすることなどが可能です。

同じオブジェクトを双方向で連携する場合の注意事項

同じオブジェクト間の連携(たとえば SMPリード⇔SFDCリード)を双方向に設定した場合、連携による更新が、次回バッチで再度更新として認識されてしまうため、一度更新対象となったレコードが、バッチ処理のたびに延々更新される状態になってしまいます。
たとえば、リード情報を相互に更新している場合、SMP での更新が SFDC に反映され、次回バッチではその SFDC の更新が SMP に反映され、さらに次回のバッチではその SMP の更新が SFDC に反映され、、、といったように、常に差分ありとして認識されるようになります。
対策として、 SFDC でのデータ取得時の条件に、「最終更新者が連携設定したシステム管理者でない」ことを追加することで防止することが可能です。
詳しくは、「データ連携チュートリアル」の項を参照ください。

パフォーマンスについて

SMP への登録・更新パフォーマンスは SMP の API 性能に依存します。一方、SFDC への登録・更新処理は Apex コードの実行による SFDC のプラットフォーム内の処理性能に依存します。
一般的に言って、 Apex コードによる内部処理よりも、 API による処理のほうが時間がかかります。連携オブジェクトの種類に依りますが、SMP に登録・更新する場合は、 1時間あたり数百件程度連携できます。
オブジェクトマッピング単位での処理性能の目安はおおよそ、以下のとおりです。

表 1. パフォーマンスの目安
連携方向 1時間あたりの処理件数目安

SMP→SFDC

リード連携で およそ 50,000 件/時間

SFDC→SMP

リード連携で およそ 600 件/時間

SFDC→SFDC

リード参照関係の更新で およそ 1,000 件/時間

注意
処理性能は対象環境の状態やレコード内容によって変化します。あくまで参考値としてご理解ください。

また、Force.com プラットフォーム上で動作する仕組みであるため、SFDC のガバナ制限による制約を受けます。アプリケーションの処理においては、原則、制約の範囲でおさまるように実装していますが、たとえば連携対象に極端にデータサイズの大きいものが含まれる場合など、制限によってエラーとなる可能性があります。

検索結果 ""

    検索結果がありません ""