Merging Duplicate Account Records

Vault CRM’s account merge process happens through integration with Veeva Network, and extends the standard record merge to include records on CRM-specific core business objects in the merge. Merging duplicate records makes it easier for users to find the correct account.

Who can use this feature?

Configuring Account Merge for

To configure this feature:

  1. Ensure Configuring Accounts is complete.
  2. Ensure the disable_veeva_merge__v Veeva Setting check box is not selected.

Defining the Address Merge Process

By default, the losing account's addresses are copied to the winning account address. To set a standard behavior for all losing addresses, customers can define whether losing addresses are set to active, inactive, or remain unchanged. To define merge processing behavior for addresses:

  1. Select the appropriate value from the picklist on the account_address_merge_behavior__v Veeva Setting:
  • AS IS - uses the default behavior. Addresses are copied to the winning account without modifying the inactive__v field on the address__v record
  • INACTIVE - merges all addresses from the losing account and sets them as inactive. This sets the value of the Inactive flag = true for these address__v records.
  • ACTIVE - merges all addresses from the losing account and sets them as active. This sets the value of the Inactive flag = false for these address__v records.

Defining the Call Merge Process for Mobile Devices

To avoid losing call report data for recently merged accounts and causing sync errors, Vault CRM allows mobile device users to sync call reports linked to accounts removed from the system due to a merge. When mobile device users sync, call reports associated with the losing account are migrated to the winning account.

To configure call merge processing, ensure users have Read permission to the account_merge_history__v object.

Merging Duplicate Account and Person-Related Records as

For details on initiating the account record merge process, see About Record Merges in the Vault documentation.

Veeva’s custom merge process runs on the following objects:

  • account_territory__v
  • account_territory_loader__v
  • address__v
  • affiliation__v
  • call2__v
  • child_account__v
  • pricing_rule__v
  • sample_limit__v
  • sample_limit_transaction__v
  • tsf__v

For all other objects, records from the losing account are moved to the winner.

When merging accounts with different hierarchies, the losing account's hierarchy is removed.

Post Processing of Child Accounts

Child account records are processed if the parent_account__v field and/or child_account__v field references the deleted account. The deletion happens in one of the following two steps:

  1. The child account is deleted if child_account__v.parent_account__v AND child_account__v.child_account__v match the deleted account.
  2. The child account is deleted if there are already other child accounts with the same external_id__v.

The external_id__v value is always [parent_account__v]_[child_account__v]. This ensures any child accounts with the same parent and child relationship are removed.

All other child_account__v records associated with deleted accounts are reset by clearing the external_id__v fields to enforce the uniqueness of the parent / child pair in the account hierarchy.

Merging Product Metrics

During the account merge process, and after post-processing of child accounts, product metrics records are evaluated and updated to ensure data consistency. The merge process identifies duplicate product_metrics__v records using the following unique key combination:

product_metrics__v.account__v AND

product_metrics__v.location__v AND

product_metrics__v.products__v AND

product_metrics__v.detail_group__v

After the merge process, if the winning account has product metrics records, those records are retained. Product metrics records from the losing accounts(s) are retained if there is no matching record on the winner. Product metrics records from the losing account(s) that match the unique key combination are deleted to prevent duplication.

If the winning account has no existing product metrics records, the product metrics records from the losing account(s) are copied to the winning account.

These rules ensure that merged accounts reflect accurate and complete product metrics data, minimizing redundancy and improving data quality.

Merging Addresses

Merge logic for addresses depends on the value in the account_address_merge_behavior__v Veeva Setting:

  • AS IS - uses the default behavior. Addresses are copied to the winning account without modifying the inactive__v field on the address__v record
  • INACTIVE - merges all addresses from the losing account and sets them as inactive. This sets the value of the Inactive flag = true for these address__v records.
  • ACTIVE - merges all addresses from the losing account and sets them as active. This sets the value of the Inactive flag = false for these address__v records.

When an address is merged from the losing record, it is marked inactive. If it was flagged as primary it is no longer flagged as primary.

Merging Calls on Mobile Devices

To avoid losing call report data for recently merged accounts and causing sync errors, Vault CRM allows mobile device users to sync call reports linked to accounts removed from the system due to a merge. When mobile device users sync, call reports associated with the losing account are migrated to the winning account.

Merging Account Territory Records

When accounts are merged, duplicate account_territory__v records are identified based on whether they have the same account and territory values. If a duplicate account_territory__v record is active:

  • If the manual__v option is set to Yes, manual__v is set to Yes on the account_territory__v record for the winning account
  • If the rule__v option is set to Yes, rule__v is set to Yes on the account territory__v record for the winning account

If the winning account does not have an account_territory__v record, and losing accounts have them, the manual__v and rule__v fields are populated on one of the losing account records, and that record is made the winner.

The status__v field is set to Active on the winning account record, and all records from the losing account are deleted.

For example, if account1 is the winning account and account2 is the losing account, the record for account1 is preserved with rule__v selected and manual__v selected. The record for account2 is deleted.

Merging Account Territory Loader Records

Account merges are executed in the Account Territory Loader, where the winning account is aligned to all territories defined in the account_territory_loader__v (ATL) for the losing accounts. The ATL record of the “loser” account is subsequently deleted. By default, ATL record merging runs as part of Veeva’s merge process.

Merging Territory Specific Field Records

When merging accounts, custom logic ensures Territory Specific Field records are maintained for unique Account/Territory combinations:

  • If the losing account has a TSF record, but the winning account does not have an associated TSF record for the same territory, then the losing account’s TSF record is copied to the winning account
  • If both the losing account and winning account have a TSF record associated with the same territory, then the losing account’s TSF record is deleted

Merging TSF records is not configurable.

Merging Accounts with MCCP Records

When accounts in a Multichannel Cycle Plan are merged, MCCP-specific processing handles the losing account's mc_cycle_plan_target__v record and all related calculations. If both the winning and losing account are on the same MCCP, the mc_cycle_plan_target_status__v field on the losing account’s mc_cycle_plan_target__v record is set to merged__v. Targets with merged__v status are considered inactive and are excluded from future MCCP calculations and processing. MCCP admin users may delete merged mc_cycle_plan_target__v records.

The following table summarizes outcomes for common account merge scenarios:

Account Merge Scenario

Post-Merge Outcome

Only the winning account is part of an MCCP

No change, since the losing account is not part of the MCCP

Only the losing account is part of an MCCP
  • The account__v lookup on the appropriate mc_cycle_plan_target__v record updates to the winning account
  • The target remains active

Both the winning and losing Accounts are part of the same MCCP
  • The mc_cycle_plan_target__v record associated with the winning account is not changed
  • The account__v lookup on the losing account's mc_cycle_plan_target__v record updates to the winning account
  • The losing account’s target record is no longer included in MCCP processing and calculations and the mc_cycle_plan_target_status_status__v field updates to merged__v

Merging Sample Limit Records

When accounts with Sample Limit records are merged via the Account Merge process, the losing account’s sample_limit__v and sample_limit_transaction__v records are compared to the winning account’s Sample Limit records of the same type, and the accounts’ sample limits are merged. This merge ensures existing Sample Limit records and their associated transactions on the losing account record are tracked after merging with the winning account.

The following fields enable Sample Limit and Sample Limit Transaction tracking for accounts:

Vault Object

Vault Field

sample_limit__v

merged__v

original_account_id__v

merge_conflict_id__v

sample_limit_transaction__v

merged__v

If the date ranges on the losing account’s existing Sample Limit records do not conflict with any of the date ranges on the winning account’s Sample Limit records, the following process occurs:

  • The original_account_id__v on the losing account's sample limit record is set to the losing account's ID
  • The losing account’s Sample Limit record and any associated Sample Limit Transactions are reparented under the winning account
  • The merged__v check box on the losing Sample Limit record and its associated Sample Limit Transaction record is selected
  • The group_id__v field on the losing Sample Limit record is updated with the winning account’s Account ID

If the date ranges on a losing account’s existing Sample Limit records conflict with date ranges on the winning account’s Sample Limit records, the following process occurs:

  • The merge_conflict__v field on the losing account’s Sample Limit record is set to the record ID of the conflicting Sample Limit on the winning account
  • The merged__v check box on the Sample Limit is selected

Merging Sample Limit Transaction Records

If the call_date__v field values on any of the losing account’s Sample Limit Transactions records are within the date range of a Sample Limit record on the winning account:

  • The merged__v check box on the Sample Limit Transaction is selected
  • The Sample Limit Transaction is reparented under the appropriate winning Sample Limit
  • The sample_limit_id__v, sample_limit_name__v, and sample_limit__v fields on the transaction are updated to match the Sample Limit Transaction’s newly parented Sample Limit

If the call_date__v field values for the losing account’s Sample Limit Transaction records are not within the date range of any Sample Limit associated with the winning account:

  • The merged__v check box on the losing account’s Sample Limit Transaction record is selected
  • The Sample Limit Transaction remains nested under the losing account’s Sample Limit record

Calculating Disbursed and Remaining Sample Quantities

After all Sample Limits and Sample Limit Transactions are reorganized using the above methods, the disbursed_quantity__v and remaining_quantity__v fields on the winning Sample Limit records are updated to include the reparented Sample Limit Transactions.

If an HCP’s Sample Limit is 20 grams of a product per quarter, when an admin merges a duplicate account record to his main record, two sample disbursements of 5 grams from the duplicate account are reparented under the master account record’s Sample Limit. On the master account’s Sample Limit record, the disbursed_quantity__v field is updated to include 10 more grams and the remaining_quantity__v field value is reduced by 10 grams.

There is no way to enforce Sample Limit violations when merging accounts. Sample Limit violations are enforced on the call report. For more information, see Enforcing Sample Limits.

Implementing a Custom Merge Process

Customers can choose to use Vault CRM’s account merge functionality or implement their own solution. If a customer implements a custom merge process, they can opt out of the Vault CRM merge process. Admins can disable Vault CRM’s account and person-related merge functionality. To do so, select the check box for the disable_veeva_merge__v Veeva Setting.

For organizations with custom merge processes, merge changes from Veeva’s Account Territory Loader merge process should not impact any custom code built to replicate ATL merging. Veeva’s ATL merge simply cleans up any duplication resulting from the regular Veeva merge process. Any custom post-process search for duplicates will find the data is already cleaned up, with nothing left to modify.

Related Topics

Merging Records in Vault

Working with Territory Specific Fields