Configurer un RuleSet dans DQE One Standalone

Un RuleSet définit comment DQE One Standalone décide quels enregistrements sont des doublons, lequel devient le « parent » (le survivant), quels doublons doivent rester séparés au lieu d'être fusionnés, et quelles valeurs de champ l'emportent lors de la fusion des enregistrements. Un RuleSet publié est nécessaire pour créer un process Unify Process ou Index Records.

Où configurer un RuleSet

Allez dans Rules Manager (navigation de gauche) pour voir tous les RuleSets que vous avez créés, avec leur source, leur date de dernière modification et leur statut (Draft ou Published). À partir de là, vous pouvez cliquer sur New ruleset, ou utiliser les actions de ligne : Clone, Download the ruleset as a JSON file, ou Delete.

Delete est verrouillé pour deux raisons différentes : un RuleSet utilisé par un process actuellement en cours d'exécution se déverrouille à nouveau une fois ce run terminé, mais un RuleSet rattaché à un process qui a actuellement — ou a déjà eu — un Scheduler reste verrouillé définitivement, même après avoir mis ce planning en Inactive (voir Schedule a process in DQE One Standalone et Maintain your data and processes in DQE One Standalone).

Vous pouvez aussi accéder à l'éditeur depuis le sélecteur de RuleSet de l'assistant de création de process, en cliquant sur Create new set — cela ouvre le même éditeur, déjà relié à ce process.

Une fois la source de données et l'objet choisis (ainsi qu'un Label/Description), l'éditeur comporte lui-même 3 onglets : Matching Rules, Sibling, Parent Rules et Merge Rules.

Matching Rules

Une Matching Rule est une « étape » (affichée comme son propre onglet nommé, par ex. « Name / Email ») composée d'une ou plusieurs lignes Field Match. Chaque champ que vous ajoutez est comparé à l'aide d'une Method — une combinaison prête à l'emploi d'un algorithme de blocage, d'un algorithme de distance floue, et d'une tolérance par défaut. La liste réelle des Methods disponibles :

La Tolérance par défaut est la valeur préremplie par chaque Method sur la ligne Field Match (vous pouvez toujours la modifier). La colonne Exemple illustre le type de variation que chaque Method est conçue pour détecter — les algorithmes de matching sous-jacents sont propriétaires et compilés, donc ces exemples doivent être considérés comme illustratifs, et non comme une garantie du comportement exact de correspondance/non-correspondance.

Pour chaque ligne Field Match, vous définirez :

• Select a Field — le champ à comparer.
• Ignore Empties — coché par défaut ; ignore la règle pour les enregistrements dont le champ est vide.
• Tolerance — de 0 à 100 %, le degré de flou toléré pour la correspondance sur ce champ.
• Noise — permet de lister en option des mots/expressions à ignorer dans la comparaison (utile pour des éléments récurrents comme « SARL » dans les noms d'entreprise, si la Method choisie ne le couvre pas déjà).
• Field Relation — comment cette ligne se rapporte à la prochaine Field Match de la liste : No relation, Cross Check, Append ou Invert.

Advanced Rules : pour un contrôle fin, chaque Field Match dispose d'une section « Advanced Rules » qui expose l'algorithme de blocage brut (KeyAlgo) et l'algorithme de distance (DistAlgo) que la Method choisie définit par défaut, ainsi qu'un Weight optionnel. Vous n'avez généralement pas besoin d'y toucher — la liste déroulante Method ci-dessus choisit déjà des valeurs par défaut sensées — mais cette section est là si vous devez combiner un algorithme de clé spécifique avec un algorithme de distance spécifique.

Un exemple réel, tiré des règles par défaut de DQE pour un Lead Salesforce (3 Matching Rules distinctes — "Name / Email", "Name / Phone", "Name / Address") :

Name / Email:
  Email      → "Analyze an EMAIL"     (Tolerance 0%)
  LastName   → "Analyze a LAST NAME"  (Tolerance 15%)
  FirstName  → "Analyze a FIRST NAME" (Tolerance 15%)

Les Matching Rules sont évaluées dans l'ordre, et cet ordre influence le résultat. Les recommandations de DQE donnent cet exemple : Règle 1 — correspondance exacte sur Email ; Règle 2 — correspondance floue sur First Name + Last Name (tolérance 80 %) ; Règle 3 — Cross Check entre Home Phone et Mobile Phone.

Sibling, Parent Rules

Parent Rules — comment le record survivant est choisi

Lorsque plusieurs enregistrements correspondent, l'un d'eux devient le parent (l'enregistrement qui survit) et les autres deviennent ses doublons. Les Parent Rules déterminent lequel :

Le défaut appliqué par DQE pour un RuleSet standard Lead/Contact/Account est Oldest first, sur CreatedDate — « conserver l'enregistrement le plus ancien comme parent ». Pour un RuleSet multi-objet Contact+Lead, le défaut est plutôt Parent is Primary, en conservant toujours le Contact.

Vous pouvez empiler plusieurs Parent Rules. La première décide ; chaque règle suivante ne fait que départager les égalités laissées par la précédente. Exemple : empiler Newest first puis Contains (Email contient @dqe-software.com) — si deux enregistrements partagent exactement la même date, celui avec l'email interne l'emporte ; sinon, l'enregistrement le plus récent l'emporte directement et la deuxième règle n'intervient jamais.

Sibling Rules — garder volontairement des enregistrements correspondants séparés

Tout enregistrement qui n'est pas choisi comme parent est, de façon informelle, un sibling de ce parent. Une Sibling Rule est la façon de dire à DQE One Standalone : « ces enregistrements correspondent, mais ne les fusionnez pas en un seul — gardez-les liés, mais séparés. » Les enregistrements d'une même source qui correspondent entre eux sont eux aussi automatiquement traités comme des siblings, sans règle nécessaire.

Cliquez sur Add a new Sibling Rule et choisissez une condition :

• Record condition — un champ de l'enregistrement remplit une condition (égal, différent, supérieur/inférieur à, commence par, finit par, contient, dans la liste, pas dans la liste).
• Parent condition / Child condition — identique, mais testée uniquement sur le champ du parent ou uniquement sur celui du child. Exemple : Child Email finit par @test.com → les enregistrements de test ne sont jamais fusionnés dans un vrai parent.
• Parent child condition — une condition sur le parent ET une condition sur le child doivent être vraies toutes les deux. Exemple : Parent Country égal à FR ET Child Country égal à US → les correspondances inter-pays restent séparées.
• Date condition — compare le champ de date choisi entre tous les enregistrements du groupe concerné, deux par deux : un opérateur direct (égal, supérieur à, inférieur à, etc.) compare les dates elles-mêmes, tandis qu'un opérateur « delta » compare l'écart entre deux dates (en jours) à un seuil années/mois/jours que vous définissez. Exemple : CreatedDate, delta ≥ 1 an → les enregistrements créés à plus d'un an d'intervalle restent siblings au lieu d'être fusionnés.
• Record value test — Sibling si n'importe quel enregistrement du groupe concerné a la valeur de ce champ dans une liste que vous fournissez. Exemple : Status dans la liste Test, Demo → un seul enregistrement de test/démo garde tout le groupe en siblings.
• Parent child value test — Sibling si la valeur du parent est dans une première liste ET qu'au moins un child a sa valeur dans une seconde liste. Exemple : Parent Type dans Prospect ET un child avec Type dans Customer → la paire est gardée séparée.
• Parent child value non empty — la valeur du parent et celle du child doivent toutes les deux être renseignées. Exemple : le parent et un child ont déjà tous les deux Legacy_ID__c renseigné → chacun garde sa propre référence legacy au lieu d'être fusionné.
• Multiple values / Multiple tuples — le groupe est traité comme des siblings si un champ (ou une combinaison de champs) a plus d'une valeur distincte dans le groupe. Les deux disposent d'une option Ignore Empties (cochée par défaut) qui exclut les valeurs vides du comptage. Exemple : le groupe a deux valeurs Email différentes → conservées en siblings pour qu'aucune des deux adresses ne soit perdue lors de la fusion.
• Tuple cardinality test — compare le nombre de valeurs distinctes d'une combinaison de champs, à l'aide d'un opérateur que vous choisissez (égal, différent, supérieur/inférieur à, etc.), à un nombre que vous définissez. Dispose aussi de la même option Ignore Empties. Exemple : la combinaison (Country, Language) a une cardinalité supérieure à 1 dans le groupe → scindé en siblings dès qu'il mélange plus d'une paire pays/langue.
• (Custom) — écrivez votre propre condition.

Les noms de champs, listes et seuils des exemples ci-dessus sont des illustrations génériques du comportement de chaque condition (vérifiées sur les fonctions de filtre réelles), pas des valeurs issues d'un org réel — adaptez-les à vos propres champs.

Exemple réel — traiter des enregistrements comme des siblings au lieu de les fusionner lorsqu'un champ de regroupement est égal à une valeur spécifique :

Record condition:
  Field: Compte_de_regroupement__c
  Condition: in list
  Value: CLIENT ESPACE PRO

Si vous utilisez Salesforce : les enregistrements marqués comme siblings y sont affichés comme « Unique », et non « Sibling » — le champ de résultat de DQE fait correspondre Parent → « Parent », Child → « Child », et Sibling → « Unique ». Gardez cela à l'esprit si vous vérifiez des résultats dans Salesforce.

Merge Rules

Les Merge Rules déterminent quelle valeur l'emporte, champ par champ, lorsqu'un doublon est fusionné dans son parent. Pour chaque champ, vous associez une ou plusieurs méthodes, évaluées dans l'ordre comme une cascade : la première méthode qui donne une réponse claire l'emporte ; si elle trouve le parent et le child égaux pour ce critère, l'évaluation passe à la méthode suivante ; si toutes les méthodes les trouvent égaux, la valeur existante du parent est conservée.

Les méthodes terminales (Concatenate Lists, Sum of Fields, Custom) calculent directement la valeur finale et ne peuvent pas être combinées avec les autres méthodes, basées sur des conditions, pour le même champ.

Regrouper des champs ensemble

Si plusieurs champs doivent toujours provenir du même enregistrement (pour éviter de mélanger des lignes d'adresse issues de deux enregistrements sources différents), regroupez-les dans un Group et marquez l'un d'eux comme Main Field. Les méthodes que vous définissez sur le Main Field s'appliquent à tout le groupe.

Exemple : regrouper Street, City et ZipCode sous un groupe nommé ADDRESS, définir Street comme Main Field avec "Newer Than" — l'enregistrement qui l'emporte sur Street fournit aussi City et ZipCode, ensemble.

Vous pouvez cliquer sur Preview pour voir ce que la logique de fusion générée produirait avant de publier.

Publication

Cliquez sur Publish. Un RuleSet ne peut être publié que s'il contient au moins une Matching Rule avec au moins une Field Match, et au moins une Parent Rule — les Merge Rules et les Sibling Rules sont optionnelles. Si l'une de ces conditions manque, vous verrez "Publication error: Required rules missing".

La publication ne verrouille pas définitivement le RuleSet contre toute modification ultérieure — il n'existe pas de bouton "Unpublish". Un RuleSet n'est verrouillé (en lecture seule) que temporairement, tant qu'un process qui l'utilise est en cours d'exécution ; une fois ce run terminé, vous pouvez à nouveau le modifier.