Merging Duplicate Account Records
Users can merge duplicate account information while preserving the original information. 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?
- Browser Users
- Users do not require an additional license
- Business Admin Users
Configuring Account Merge for
Business Admin Users
To configure this feature:
- Ensure Configuring Accounts is complete.
- 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:
- 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
Business Admin Users
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.
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.
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 |
|
|
Both the winning and losing Accounts are part of the same MCCP |
|
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.
