Configure a RuleSet in DQE One Standalone

A RuleSet defines how DQE One Standalone decides which records are duplicates, which one becomes the "parent" (the survivor), which duplicates should be kept separate instead of merged, and which field values win when records are merged. You need a published RuleSet to create a Unify Process or an Index Records process.

Where to configure a RuleSet

Go to Rules Manager (left navigation) to see every RuleSet you've created, with its source, last modification date, and status (Draft or Published). From here you can click New ruleset, or use the row actions: Clone, Download the ruleset as a JSON file, or Delete.

Delete is locked for two different reasons: a RuleSet used by a process that's currently running gets unlocked again once that run finishes, but a RuleSet attached to a process that currently has — or has ever had — a Scheduler stays locked permanently, even after you switch that schedule to Inactive (see Schedule a process in DQE One Standalone and Maintain your data and processes in DQE One Standalone).

You can also reach the editor from the process wizard's RuleSet picker by clicking Create new set — this opens the same editor, already linked back to that process.

After picking a data source and object (and a Label/Description), the editor itself has 3 tabs: Matching Rules, Sibling, Parent Rules and Merge Rules.

Matching Rules

A Matching Rule is one "step" (shown as its own named tab, e.g. "Name / Email") made of one or more Field Match rows. Each field you add is compared using a Method — a ready-made combination of a blocking algorithm, a fuzzy-distance algorithm, and a default tolerance. The real list of Methods available:

Default Tolerance is the value each Method pre-fills on the Field Match row (you can still change it). The Example column illustrates the kind of variation each Method is built to catch — the underlying matching algorithms are proprietary and compiled, so treat these as illustrative, not a guarantee of exact match/no-match behavior.

For each Field Match row, you'll set:

• Select a Field — the field to compare.
• Ignore Empties — checked by default; skips the rule for records where the field is empty.
• Tolerance — 0 to 100%, how fuzzy the match can be for this field.
• Noise — optionally list words/phrases to ignore in the comparison (useful for recurring boilerplate like "SARL" in company names, if not already covered by the chosen Method).
• Field Relation — how this row relates to the next Field Match in the list: No relation, Cross Check, Append or Invert.

Advanced Rules: for fine control, each Field Match has an "Advanced Rules" section exposing the raw blocking algorithm (KeyAlgo) and distance algorithm (DistAlgo) that the chosen Method sets by default, plus an optional Weight. You generally don't need to touch this — the Method picklist above already picks sensible defaults — but it's there if you need to mix a specific key algorithm with a specific distance algorithm.

A real example, from DQE's own default rules for a Salesforce Lead (3 separate Matching Rules — "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%)

Matching Rules are evaluated in order, and their order affects the result. DQE's own guidance gives this example: Rule 1 — exact match on Email; Rule 2 — fuzzy match on First Name + Last Name (tolerance 80%); Rule 3 — Cross Check Home Phone and Mobile Phone.

Sibling, Parent Rules

Parent Rules — choosing which record survives

When several records match, one becomes the parent (the record that survives) and the rest become its duplicates. Parent Rules decide which one:

DQE's own default for a standard Lead/Contact/Account RuleSet is Oldest first, by CreatedDate — "keep the oldest record as the parent." For a multi-object Contact+Lead RuleSet, the default is instead Parent is Primary, always keeping the Contact.

You can stack more than one Parent Rule. The first one decides; any rule after it only breaks ties left by the one before it. Example: stack Newest first then Contains (Email contains @dqe-software.com) — if two records share the exact same date, the one with the internal email wins; otherwise the newest record wins outright and the second rule never comes into play.

Sibling Rules — keeping matched records separate on purpose

Every record that isn't chosen as the parent is informally a sibling of that parent. A Sibling Rule is how you tell DQE One Standalone: "these records did match, but don't merge them into one — keep them linked, but separate." Records from the same source that match each other are also automatically treated as siblings, with no rule needed.

Click Add a new Sibling Rule and pick a condition:

• Record condition — a field on the record meets a condition (equals, not equals, greater/less than, starts with, ends with, has, in list, not in list).
• Parent condition / Child condition — same, tested only on the parent's or only on the child's field. Example: Child Email ends with @test.com → test records never get merged into a real parent.
• Parent child condition — a condition on the parent AND a condition on the child must both be true. Example: Parent Country equals FR AND Child Country equals US → cross-country matches stay separate.
• Date condition — compares the chosen date field across every record in the matched group, two at a time: a direct operator (equals, greater than, less than, etc.) compares the dates themselves, while a "delta" operator compares the gap between two dates (in days) against a years/months/days threshold you set. Example: CreatedDate, delta ≥ 1 year → records created more than a year apart stay siblings instead of merging.
• Record value test — Sibling if any record in the matched group has this field's value in a list you provide. Example: Status in list Test, Demo → a single test/demo record keeps the whole group as siblings.
• Parent child value test — Sibling if the parent's value is in one list AND at least one child's value is in another. Example: Parent Type in Prospect AND a child's Type in Customer → the pair is kept separate.
• Parent child value non empty — both the parent's and the child's value must be filled in. Example: both the parent and a child already have Legacy_ID__c filled in → each keeps its own legacy reference instead of merging.
• Multiple values / Multiple tuples — the group is treated as siblings if a field (or a combination of fields) has more than one distinct value across the group. Both have an Ignore Empties option (checked by default) that excludes blank values from the count. Example: the group has two different Email values → kept as siblings so neither address is lost in the merge.
• Tuple cardinality test — compares how many distinct values a field combination has, using an operator you choose (equals, not equals, greater/less than, etc.), against a number you set. Also has the same Ignore Empties option. Example: the (Country, Language) combination has a cardinality greater than 1 across the group → split into siblings whenever it mixes more than one country/language pair.
• (Custom) — write your own condition.

Field names, lists and thresholds in the examples above are generic illustrations of how each condition behaves (confirmed against the actual filter functions), not values pulled from a real org — adapt them to your own fields.

Real example — treat records as siblings instead of merging them when a grouping field equals a specific value:

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

If you use Salesforce: records tagged as siblings are shown there as "Unique", not "Sibling" — DQE's result field maps Parent → "Parent", Child → "Child", and Sibling → "Unique". Keep this in mind if you're cross-checking results in Salesforce.

Merge Rules

Merge Rules decide which value wins, field by field, when a duplicate is merged into its parent. For each field, you attach one or more methods, evaluated in order like a waterfall: the first method that returns a clear answer wins; if it finds the parent and child equal for that purpose, evaluation moves to the next method; if every method finds them equal, the parent's existing value is kept.

Terminal methods (Concatenate Lists, Sum of Fields, Custom) compute the final value directly and can't be combined with the other, condition-based methods on the same field.

Grouping fields together

If several fields must always come from the same record (so you don't end up mixing address lines from two different source records), put them in a Group and mark one as the Main Field. Whatever methods you set on the Main Field apply to the whole group.

Example: group Street, City and ZipCode under a group named ADDRESS, set Street as the Main Field with "Newer Than" — whichever record wins on Street also provides City and ZipCode, together.

You can click Preview to see what the generated merge logic would produce before publishing.

Publishing

Click Publish. A RuleSet can only be published once it has at least one Matching Rule with at least one Field Match, and at least one Parent Rule — Merge Rules and Sibling Rules are optional. If either requirement is missing, you'll see "Publication error: Required rules missing".

Publishing does not permanently lock the RuleSet from further edits — there's no "Unpublish" button. A RuleSet is only temporarily locked (read-only) while a process using it is actively running; once that run finishes, you can edit it again.