重要な制限事項

重要な制限事項機能面における制限事項ご利用にあたっての注意事項パフォーマンスについて機能面における制限事項削除データは連携しません連携元のレコードを削除した場合でも、自動的に連携先のデータを削除することはありません。手動で連携先のデータを削除する必要があります。リードデータを手動マージした場合も同様に、連携先でも同様にマージや削除を行う必要があります。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時間あたりの処理件数目安SMP→SFDCリード連携でおよそ50,000件/時間SFDC→SMPリード連携でおよそ600件/時間SFDC→SFDCリード参照関係の更新でおよそ1,000件/時間注意処理性能は対象環境の状態やレコード内容によって変化します。あくまで参考値としてご理解ください。また、Force.comプラットフォーム上で動作する仕組みであるため、SFDCのガバナ制限による制約を受けます。アプリケーションの処理においては、原則、制約の範囲でおさまるように実装していますが、たとえば連携対象に極端にデータサイズの大きいものが含まれる場合など、制限によってエラーとなる可能性があります。