Choosing Which Record Remains After a Merge

At the bottom of the Master tab, you configure how Insycle evaluates your rules across all records in a duplicate group.

• By Priority (recommended) — Evaluates rules sequentially from top to bottom. As soon as one record uniquely meets a rule, it becomes the master and the remaining rules are skipped. This is the right choice for most deduplication processes, as it provides flexible fallback-based master selection.
• Absolute — Requires the master record to simultaneously match every rule on your list. For example, if you need the master to be both a customer and assigned to an active owner, Absolute ensures only records meeting both criteria are selected. However, Absolute frequently results in no master being identified, since records must satisfy all conditions simultaneously. By Priority is the better choice for most use cases.

The image above shows the Step 3 Master tab of the Merge Duplicates module, with the Processing Method options at the bottom, By Priority selected.

Each rule you add to the Master tab consists of a field and a condition. Insycle checks each record in the duplicate group against your condition and selects the record that uniquely meets it.

How to Add a Rule

1. Navigate to Data Management > Merge Duplicates and select your database and object type. 
2. In Step 1, configure your matching fields to identify potential duplicates, then click Find. 
3. In Step 2, review the duplicate groups to confirm the results look correct before proceeding.
4. In Step 3, click the Master tab.
5. Click Add Rule.
6. Select the field you want to base the rule on.
7. Select the condition that determines which record should be chosen.
8. Repeat to add additional rules, ordering them from most to least specific.

Field Types You Can Use

You can select any field from your CRM to base a master selection rule on, including:

• Writable fields — Any field you can edit in your CRM, such as Owner, Lifecycle Stage, or Industry.
• Read-only fields — System fields like Create Date, Last Modified Date, Record ID, and engagement metrics.
• Calculated fields — Number of associated records, email engagement counts, deal amounts.
• System fields — External system IDs such as Salesforce ID, HubSpot ID, or ERP system ID.

Available Conditions

The conditions available for each rule depend on the field type selected.

Text fields:

• Is / Is not — Match or exclude an exact value.
• Contains / Does not contain — Match or exclude based on partial text.
• Regex — Use a regular expression pattern for complex matching.
• Exists / Doesn't exist — Filter based on whether the field has any value.

Date fields:

• Earliest / Latest — Select the record with the oldest or most recent date.

Number fields:

• Highest / Lowest — Select the record with the largest or smallest numeric value.

Owner fields:

• Active user — Select the record where the owner is currently an active user in your CRM.
• Exists / Doesn't exist — Filter based on whether an owner is assigned.

Email fields:

• Not role-based (info@, etc.) — Exclude generic email addresses like info@, admin@, or sales@.
• Work domain (non-Gmail, etc.) — Select records with work email addresses, excluding common personal email providers.
• Personal domain (Gmail, etc.) — Select records with personal email addresses from providers like Gmail, Yahoo, or Outlook.
• Exists / Doesn't exist — Filter based on whether an email address is present.

Picklist and lookup fields:

• Any of / Not any of — Select or exclude from multiple dropdown values at once.

Rule order determines which record becomes the master when multiple records in a group could qualify. Insycle reads rules from top to bottom and stops as soon as one record uniquely matches a rule.

For example, if your first rule is "Lifecycle Stage is Customer" and multiple records in the group are customers, no single record is selected and Insycle moves to the next rule. If your second rule is "Email is work domain" and only one of those customer records has a work domain email, that record becomes the master — even if there are additional rules below.

You can create multiple rules for the same field to establish fallback logic. Insycle evaluates them in order and stops at the first one where a single record uniquely matches. For example:

1. Lifecycle Stage is Customer
2. Lifecycle Stage is Opportunity
3. Lifecycle Stage is Lead

If no records in the group are Customers, Insycle checks for Opportunities. If no Opportunities exist, it checks for Leads. This ensures the most qualified record available within each duplicate group is selected as master.

This fallback pattern works for other scenarios as well:

• Check for synchronized records first (Salesforce ID exists), then fall back to records with owners, then fall back to the oldest record.
• Prioritize work email addresses, then personal email addresses, then any record with an email.
• Select the most engaged contact (highest email clicks), then most recently updated, then earliest created.

The image above shows the Step 3 Master tab of the Merge Duplicates module with multiple rules configured in sequence, with owner, number of employees, and annual revenue, followed by two Lifecycle Stage rules.

If none of your rules produce a unique match, Insycle cannot select a master and the duplicate group is skipped. To prevent this, add a catchall rule at the bottom of your list that will always produce a unique winner — such as "Create Date is earliest" or "Record ID is lowest." This ensures every duplicate group has a fallback when more specific rules cannot identify a clear winner.

Note: If master selection fails for a group, the Result column in your preview CSV will show "Failed" with a message indicating that Insycle could not determine a master record. Revisit your rule order and consider adding or reordering rules, or add a tiebreaker rule as a final fallback.

A common master selection strategy is to preserve records that are synchronized with external systems like another CRM or ERP platform. If you are synchronizing HubSpot with Salesforce, for example, you might structure your rules as follows:

1. Salesforce Contact ID exists — If a record is synchronized with Salesforce, it becomes the master.
2. Contact Owner exists — If no Salesforce ID exists, select a record that has an owner assigned.
3. Create Date is earliest — If no records have a Salesforce ID or an owner, merge into the oldest record.

This ensures the record your other systems depend on is always preserved, with clear fallback logic when that connection does not exist.

The image above shows the Step 3 Master tab of the Merge Duplicates module with three rules — Salesforce Contact ID exists, Contact Owner exists, and Create Date is earliest — configured in sequence.

When the quality of an email address matters for master selection, you can layer email-specific conditions to prioritize the most reliable address:

1. Email is not role-based — Exclude generic addresses like hr@company.com or info@company.com.
2. Email is work domain — Select a record with a work email address rather than a personal domain like gmail.com or outlook.com.
3. Email exists — If neither of the above conditions identifies a unique record, select whichever record has any email address at all.

This ensures you select the record with the most reliable contact information available within each duplicate group.

The image above shows three email-based rules configured in sequence on the Step 3 Master tab of the Merge Duplicates module.

Select master records based on engagement metrics when available — highest number of email clicks, most recent email opened, or highest engagement score. You can also prioritize by lifecycle stage (customers over leads) or by assignment (records with active owners).

Common strategies for contacts:

• Most engaged contact (email clicks, opens, form submissions)
• Furthest along in lifecycle stage (Customer > Opportunity > Lead)
• Most recently updated or contacted
• Record with an active owner assigned

The image above shows the Step 3 Master tab of the Merge Duplicates module with a multi-rule configuration for contacts, combining engagement metrics, lifecycle stage, and owner rules.

Prioritize records with the most associated data — the highest number of associated contacts, deals, or activities. This ensures you preserve the record with the richest relationship history.

Common strategies for companies:

• Most associated contacts or deals
• Highest annual revenue or employee count
• Record synchronized with external systems (CRM, ERP)
• Record with an active owner assigned

The image above shows the Step 3 Master tab of the Merge Duplicates module with a multi-rule configuration for companies, combining associated record counts and external system ID rules.

If you integrate with other CRMs, ERP systems, or other platforms, prioritize the record that is synchronized with those systems to avoid breaking your integration. Use an "exists" condition on the external system's ID field as your first master rule, then layer in fallback rules for cases where the sync ID is not present. See Example 1 above for how to structure this pattern.