フィールドからのメモ：単一テーブル重複排除モジュール

公開: 2021-08-18

クリーンで堅牢なCRMデータはすばらしいものであり、企業は各顧客の単一のビューをすべて1か所で提供します。 しかし、重複するレコードがデータベースに入ると、その「単一の」ビューは存在しなくなります。 重複は組織全体に頭痛の種を生み出し、売上予測、パイプライン管理、マーケティング支出、および顧客体験に悪影響を及ぼします。

CRMで「二重に見える」ことは、Salesforce管理者が直面する多くの課題の1つにすぎませんが、最も一般的なものの1つです。 おそらくそれが、DemandToolsの多くのモジュールの1つであるSingle TableDedupeが最も一般的に使用されている理由の1つです。

ここでDemandToolsの30日間の無料試用版を入手して、そのすべてのモジュールの動作を確認できます。 ただし、このブログでは、最初に試してみたいと思われるモジュールに慣れるために、単一テーブル重複排除を特に強調したいと思います。

単一テーブルの重複排除の違いは何ですか？

単一テーブル重複排除は、Salesforceのネイティブ機能が提供するものを超えて重複管理を行います。 これは次の方法で行われます。

  • Salesforceマージユーティリティは、一度に3つのレコードのみをマージでき、自動化できず、カスタムオブジェクトをマージできず、マージに関連するデータのバックアップを提供しません。 DemandToolsは、レコードレベルのバックアップを提供します。 また、その強力な重複排除機能は、大小のデータセットで機能します。 これは、Salesforceで標準オブジェクトとカスタムオブジェクトの両方をマージした最初のカスタマイズ可能な大量の重複排除ツールでした。
  • カスタムマスタールールとフィールドルール、Salesforceに保持される重複レコード、および各レコードから保持されるフィールド値を指定できる設定を提供することにより、重複をより細かく制御できます。
  • 最近DupeBlockerがDemandToolsスイートに追加されたことで、管理者は重複をプロアクティブに管理できます。
  • シングルテーブル重複排除で利用可能な統合により、ユーザーはDupeBlockerによって報告された重複を一括マージし、手動レビューのために信頼性の低い重複を報告できます。

30日間の無料トライアルで、DemandToolsが提供するすべてのものを見つけてください。

単一テーブルの重複排除は通常どのように使用されますか？

この人気のあるモジュールの一般的な使用例は次のとおりです。

重複管理

明らかなことから始めて、単一テーブル重複排除の最も一般的な使用例は、一連のマッチング手法を使用したルーチンの重複排除です。 すべてのタイプのデータに基づいて重複を見つけるための20のマッチングアルゴリズムがあります。

インポート後の重複の確認

DemandToolsスイートには、重複がCRMに入るのを防ぐのに役立つ他のツールがありますが、Single Table Dedupeは、インポートによって重複レコードが発生したかどうかを確認できます。 インポートの直後にこれを行うには、重複レコードの少なくとも1つが今日作成された一致のみを返すように単一テーブル重複排除を設定します。

フィールドルールの確立

Single Table Dedupeは、さまざまな部門にわたるデータ管理のニーズをサポートするのに効果的であり、信頼できる唯一の情報源として機能するレコードを確実に調整するのに役立ちます。 たとえば、複製をファイル形式にエクスポートして、DemandToolsにアクセスできない人を含む他の人と共有することができます。

これは、マージがどのように処理されたかを共有または文書化する必要がある場合、または営業などの他のチームが、重複がマスターレコードを表す入力を提供する必要がある場合に特に役立ちます。

フィールドルールを使用すると、各部門は、職務と目標を実行するために最も依存しているフィールドのデータがどのように処理されるかを検討できます。 そして、彼らはデータ処理でこの発言をするので、各部門の最前線でデータ品質を維持するのに役立ちます。

シングルテーブル重複排除の詳細

DemandToolsの30日間の無料トライアル中に、Single TableDedupeが提供するものを詳しく見ていきます。 DemandToolsは、Salesforce管理者が必要とするすべてのツールを備えた仮想の「スイスアーミーナイフ」と考えています。 各ツールには、重複排除や標準化から高度なデータ管理機能まで、特別な目的があります。 それらすべてを試乗できるように、トレーニング資料、ヘルプドキュメント、および他のDemandToolsユーザーからのヒントへのアクセスも提供します。

それまでの間、このブログを閉じて、追加機能、処理ツール、サポート、および単一テーブル重複排除の使用例のリストを示します。 試用中に見逃さないように、このリストで最も重要な機能を確認してください。

特徴
  • 29の構築済みシナリオとマスタールールを使用してインストールします
  • カスタムマスタールール–ユーザーがマスターとして保持するレコードの属性を定義できるようにします
  • カスタムフィールドルール–各フィールドに保持される値のユーザー指定を可能にします
  • レコードのすべてまたはサブセットを評価する
  • 標準フィールドとカスタムフィールドに一致
  • レコードのすべてまたはサブセットに一致する
  • 20のマッチングアルゴリズムが含まれ、6つはカスタマイズ可能
  • ファジー/音声マッチング機能
  • 重複を確認するときに表示されるフィールドをカスタマイズします–マスターレコードを決定するのに役立ちます
処理ツール
  • 結果グリッド
    • 処理する前に、各グループで見つかった重複と選択したマスターを確認します。 これにより、ユーザーは重複するグループを選択してマージまたは無視でき、データがマージされていない場合でも、フィールドレベルのデータのリアルタイム編集をサポートして迅速に修正できます。
  • 重複をエクスポート
    • 提案されたマージをDemandTools以外のユーザーと共有するのに最適です。 または、重複する結果が各グループのマスターを選択するために他のチームからの入力を必要とする場合に使用します。
  • マージ後のファイル
    • データの復元を支援し、マージによって生じる所有権の変更を管理するために、4つのマージ後ファイルが作成されます。
      • レコードファイルのマージ–システム間のレコードを識別するために使用されるIDがマージによって削除された場合に、システムの同期を維持するのに役立ちます。
      • {オブジェクト}重複排除マージデータファイル–マージを元に戻すのに役立つように、マージされたレコードのすべてのフィールドレベルの値を表示します。
      • 非マスター所有者変更ファイル–異なる所有者のレコードがマージされた場合にのみ生成されます。 レコードのマージから削除された可能性のある共有とレコードの可視性のために、アカウントチームにメンバーを追加するのを容易にします。
      • サブオブジェクト所有者変更ファイル–特定のサブオブジェクトに対して[マスター所有者に再割り当て]オプションが選択されている場合、必要に応じて所有権の復元に役立つサブオブジェクト所有者変更ファイルが作成されます。
    • ログファイル
      • トラブルシューティングに役立つように、処理中に発生したエラー、処理の日時、およびその他のプロセス変数を報告します。
    • シナリオの保存
      • 新しいシナリオを作成するか、既存のシナリオを変更し、将来の手動またはスケジュールされた処理とデータのマージ方法の迅速な呼び出しのために設定を保存します。
    • 処理オプション
      • SOAPおよびバルクAPIバッチサイズ–バッチサイズを制御して、速度を向上させ、使用されるAPI呼び出しの数を減らします。
      • リード/ケース/テリトリー割り当てルール–デフォルトのルールを呼び出して、データをマージしてもレコードの所有権ルールが中断されないようにします。
      • マージタスクの概要–各プロセス中にマージされたレコードの数を追跡します。
サポート
  • 自動化/シナリオスケジューリング
  • オブジェクト：標準およびカスタム
  • フィールド：標準およびカスタム
  • 国際および2バイト文字
  • SOAPAPI処理
  • バルクAPI処理
ユースケース
  • 重複するアカウントをマージし、階層構造を保持します
  • 今日インポートされたデータによって作成された重複のみを検索してマージします
  • 特定の地域のすべてのアカウントの親アカウントIDを照合して、親アカウントを共有するアカウントを特定します
  • アカウント名に基づいて一致するレコードに親アカウントを割り当てます
  • 1つのアカウント名が頭字語で、その重複がスペルアウトされたバージョンであるアカウントの重複を検索します（例：「IBM」および「InternationalBusinessMachines」）。
  • 接尾辞が異なるアカウントの重複を検索します。例：「ValidityInc。」、「Validity」、「ValidityIncorporated」
  • アカウントをマージするときは、最も古いレコードをマスターとして保持しますが、顧客レコードタイプのレコードからアカウント番号を保持し、顧客をアカウントレコードタイプとして保持します
  • アカウントをマージするときは、最も機会の多いアカウントをマスターレコードとして保持します
  • フィールド内の単語が同じであるが単語の順序が異なる重複を検索します。例：「Cavitch、Familo、Durkin」と「DurkinCavitchandFamilo」
  • 電子メールを照合して連絡先またはリードの重複を特定し、電子メールアドレスが名前と一致しない場合は、レコードから誤った電子メールアドレスを削除します
  • 1つのレコードにその人のフルネームがあり、もう1つのレコードにニックネームがリストされている連絡先またはリードの一致を検索します（例：「JimHinkle」および「JamesHinkle」）。
  • 連絡先またはリードをマージするときは、重複グループ内のすべてのレコードのすべての電子メールアドレスと電話番号を保持します
  • 同じアカウントIDに関連しない連絡先の重複をマージする
  • 連絡先をマージするときは、最も多くのタスクとイベントを含む連絡先をマスターとして保持します
  • 会社の異なる地理的地域で使用される複数のSalesforceインスタンスを組み合わせた後、アセットをマージします
  • マージオポチュニティが今年度に作成され、同じステータスで同じ金額の場合
  • DupeBlockerによって報告された重複をまとめてマージする
  • Salesforce DuplicateManagementによって報告された重複をまとめてマージする
  • レコードをマスターとして保持するか、まったくマージしない他のチームからのフィードバックのために複製をエクスポートします
  • SalesforceのDemandToolsによってマージされた実績