Configurar un RuleSet en DQE One Standalone

Un RuleSet define cómo DQE One Standalone decide qué registros son duplicados, cuál de ellos se convierte en el "parent" (el superviviente), qué duplicados deben mantenerse separados en lugar de fusionarse, y qué valores de campo prevalecen al fusionar registros. Necesita un RuleSet publicado para crear un proceso Unify Process o Index Records.

Dónde configurar un RuleSet

Vaya a Rules Manager (navegación izquierda) para ver todos los RuleSets que ha creado, con su fuente, fecha de última modificación y estado (Draft o Published). Desde aquí puede hacer clic en New ruleset, o usar las acciones de fila: Clone, Download the ruleset as a JSON file, o Delete.

Delete está bloqueado por dos motivos distintos: un RuleSet usado por un proceso actualmente en ejecución se desbloquea de nuevo en cuanto ese run termina, pero un RuleSet vinculado a un proceso que tiene actualmente — o ha tenido alguna vez — un Scheduler queda bloqueado de forma permanente, incluso después de poner ese planificador en Inactive (véase Schedule a process in DQE One Standalone y Maintain your data and processes in DQE One Standalone).

También puede acceder al editor desde el selector de RuleSet del asistente de creación de procesos, haciendo clic en Create new set — esto abre el mismo editor, ya vinculado a ese proceso.

Tras elegir una fuente de datos y un objeto (y un Label/Description), el propio editor tiene 3 pestañas: Matching Rules, Sibling, Parent Rules y Merge Rules.

Matching Rules

Una Matching Rule es un "paso" (mostrado como su propia pestaña con nombre, p. ej. "Name / Email") formado por una o varias filas Field Match. Cada campo que añade se compara usando un Method — una combinación ya definida de un algoritmo de bloqueo, un algoritmo de distancia difusa, y una tolerancia por defecto. La lista real de Methods disponibles:

Default Tolerance es el valor que cada Method precarga en la fila Field Match (puede cambiarlo). La columna Ejemplo ilustra el tipo de variación que cada Method está diseñada para detectar — los algoritmos de matching subyacentes son propietarios y están compilados, así que trátelos como ilustrativos, no como una garantía del comportamiento exacto de coincidencia/no coincidencia.

Para cada fila Field Match, definirá:

• Select a Field — el campo a comparar.
• Ignore Empties — marcado por defecto; omite la regla para los registros cuyo campo está vacío.
• Tolerance — de 0 a 100 %, cuán difusa puede ser la coincidencia para este campo.
• Noise — permite listar opcionalmente palabras/frases a ignorar en la comparación (útil para elementos recurrentes como "SARL" en nombres de empresa, si el Method elegido no lo cubre ya).
• Field Relation — cómo se relaciona esta fila con el siguiente Field Match de la lista: No relation, Cross Check, Append o Invert.

Advanced Rules: para un control fino, cada Field Match tiene una sección "Advanced Rules" que expone el algoritmo de bloqueo bruto (KeyAlgo) y el algoritmo de distancia (DistAlgo) que el Method elegido fija por defecto, además de un Weight opcional. Normalmente no necesita tocar esto — la lista desplegable Method de arriba ya elige valores por defecto razonables — pero está ahí si necesita combinar un algoritmo de clave específico con un algoritmo de distancia específico.

Un ejemplo real, de las reglas por defecto de DQE para un Lead de Salesforce (3 Matching Rules independientes — "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%)

Las Matching Rules se evalúan en orden, y ese orden afecta al resultado. Las propias indicaciones de DQE dan este ejemplo: Regla 1 — coincidencia exacta en Email; Regla 2 — coincidencia difusa en First Name + Last Name (tolerancia 80 %); Regla 3 — Cross Check entre Home Phone y Mobile Phone.

Sibling, Parent Rules

Parent Rules — cómo se elige el registro que sobrevive

Cuando varios registros coinciden, uno de ellos se convierte en el parent (el registro que sobrevive) y el resto se convierten en sus duplicados. Las Parent Rules deciden cuál:

El valor por defecto de DQE para un RuleSet estándar Lead/Contact/Account es Oldest first, por CreatedDate — "mantener el registro más antiguo como parent". Para un RuleSet multiobjeto Contact+Lead, el valor por defecto es en cambio Parent is Primary, manteniendo siempre el Contact.

Puede apilar más de una Parent Rule. La primera decide; cualquier regla posterior solo resuelve los empates dejados por la anterior. Ejemplo: apilar Newest first y luego Contains (Email contiene @dqe-software.com) — si dos registros comparten exactamente la misma fecha, gana el que tiene el correo interno; en caso contrario, el registro más reciente gana directamente y la segunda regla nunca entra en juego.

Sibling Rules — mantener a propósito registros coincidentes separados

Todo registro que no se elige como parent es, de manera informal, un sibling de ese parent. Una Sibling Rule es la forma de decirle a DQE One Standalone: "estos registros sí coinciden, pero no los fusione en uno — manténgalos vinculados, pero separados." Los registros de la misma fuente que coinciden entre sí también se tratan automáticamente como siblings, sin necesidad de ninguna regla.

Haga clic en Add a new Sibling Rule y elija una condición:

• Record condition — un campo del registro cumple una condición (igual, distinto, mayor/menor que, empieza por, termina en, contiene, en lista, no en lista).
• Parent condition / Child condition — lo mismo, probado solo en el campo del parent o solo en el del child. Ejemplo: Child Email termina en @test.com → los registros de prueba nunca se fusionan en un parent real.
• Parent child condition — una condición en el parent Y una condición en el child deben ser ambas verdaderas. Ejemplo: Parent Country igual a FR Y Child Country igual a US → las coincidencias entre países distintos permanecen separadas.
• Date condition — compara el campo de fecha elegido entre todos los registros del grupo coincidente, dos a la vez: un operador directo (igual, mayor que, menor que, etc.) compara las fechas directamente, mientras que un operador "delta" compara la diferencia entre dos fechas (en días) frente a un umbral de años/meses/días que usted define. Ejemplo: CreatedDate, delta ≥ 1 año → los registros creados con más de un año de diferencia permanecen como siblings en lugar de fusionarse.
• Record value test — Sibling si cualquier registro del grupo coincidente tiene el valor de este campo en una lista que usted proporciona. Ejemplo: Status en la lista Test, Demo → un único registro de prueba/demo mantiene todo el grupo como siblings.
• Parent child value test — Sibling si el valor del parent está en una lista Y al menos un valor de un child está en otra. Ejemplo: Parent Type en Prospect Y un child con Type en Customer → el par se mantiene separado.
• Parent child value non empty — el valor del parent y el del child deben estar ambos rellenados. Ejemplo: tanto el parent como un child ya tienen Legacy_ID__c rellenado → cada uno conserva su propia referencia legacy en lugar de fusionarse.
• Multiple values / Multiple tuples — el grupo se trata como siblings si un campo (o una combinación de campos) tiene más de un valor distinto en el grupo. Ambas tienen una opción Ignore Empties (marcada por defecto) que excluye los valores vacíos del recuento. Ejemplo: el grupo tiene dos valores de Email distintos → se conservan como siblings para que ninguna de las dos direcciones se pierda en la fusión.
• Tuple cardinality test — compara cuántos valores distintos tiene una combinación de campos, usando un operador que usted elige (igual, distinto, mayor/menor que, etc.), frente a un número que usted define. También tiene la misma opción Ignore Empties. Ejemplo: la combinación (Country, Language) tiene una cardinalidad mayor que 1 en el grupo → se divide en siblings siempre que mezcle más de un par país/idioma.
• (Custom) — escriba su propia condición.

Los nombres de campo, listas y umbrales de los ejemplos anteriores son ilustraciones genéricas de cómo se comporta cada condición (confirmadas en las funciones de filtro reales), no valores tomados de un org real — adáptelos a sus propios campos.

Ejemplo real — tratar registros como siblings en lugar de fusionarlos cuando un campo de agrupación es igual a un valor específico:

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

Si usa Salesforce: los registros marcados como siblings se muestran allí como "Unique", no "Sibling" — el campo de resultado de DQE asigna Parent → "Parent", Child → "Child", y Sibling → "Unique". Téngalo en cuenta si está verificando resultados en Salesforce.

Merge Rules

Las Merge Rules deciden qué valor prevalece, campo por campo, cuando un duplicado se fusiona en su parent. Para cada campo, asocia uno o varios métodos, evaluados en orden como una cascada: el primer método que devuelve una respuesta clara prevalece; si encuentra el parent y el child iguales para ese propósito, la evaluación pasa al siguiente método; si todos los métodos los encuentran iguales, se conserva el valor existente del parent.

Los métodos terminales (Concatenate Lists, Sum of Fields, Custom) calculan el valor final directamente y no pueden combinarse con los demás métodos, basados en condiciones, en el mismo campo.

Agrupar campos

Si varios campos deben proceder siempre del mismo registro (para evitar mezclar líneas de dirección de dos registros fuente distintos), agrúpelos en un Group y marque uno de ellos como Main Field. Los métodos que defina en el Main Field se aplican a todo el grupo.

Ejemplo: agrupar Street, City y ZipCode bajo un grupo llamado ADDRESS, definir Street como Main Field con "Newer Than" — el registro que gana en Street también aporta City y ZipCode, juntos.

Puede hacer clic en Preview para ver qué produciría la lógica de fusión generada antes de publicar.

Publicación

Haga clic en Publish. Un RuleSet solo puede publicarse una vez que tiene al menos una Matching Rule con al menos una Field Match, y al menos una Parent Rule — las Merge Rules y las Sibling Rules son opcionales. Si falta alguno de estos requisitos, verá "Publication error: Required rules missing".

Publicar no bloquea de forma permanente el RuleSet frente a futuras ediciones — no existe un botón "Unpublish". Un RuleSet solo queda bloqueado (en modo solo lectura) temporalmente mientras un proceso que lo usa está en ejecución; una vez que ese run termina, puede volver a editarlo.