Salesforce Merge - Unchecked

Home > DemandTools for AppExchange Modules > DemandTools Cleansing Modules > Salesforce Merge - Unchecked

The following information should be considered when the "Use Salesforce Merge" Check Box is unchecked on the duplicate grid screen of the Single Table Dedupe:

NOTE: These items no longer apply when checking the "Use Salesforce Merge" for ACCOUNTS, CONTACTS, AND LEADS. Using the Salesforce Merge is the new default when creating a scenario from scratch and/or using a prebuilt scenario for ACCOUNTS, CONTACTS, AND LEADS. If de-duping any other object these caveats will apply.....Please review carefully!

Objects owned by inactive users:

In PRE-1.7 versions of DemandTools, Contacts, Opportunities, Leads, and Cases would only be merged if they were owned by an Active user. For example, if an opportunity within an Account being merged into a master Account was owned by an Inactive User, the Opportunity would NOT be merged to the master account. You would need to first change the ownership of the opportunity to an active user, and then run the merge.

In 2.0, we have added the ability to merge objects owned by inactive users, and KEEP THE OWNERSHIP HISTORY. In step#3 Merge Control, you can select the “Keep Ownership” option under “Inactive Ownership Exceptions”. This will reactivate the inactive user just long enough to transfer the object to the master, and then deactivate the user once again. YOU WILL NEED A SPARE SALESFORCE LICENSE TO USE THIS OPTION. You also have the option to change the ownership of these objects to the Master Owner, and/or the Current User.

Tasks and Events that are owned by inactive users will be moved in the deduplication process.

Archived completed activities:

Completed Activities will only be moved if they are less than a year old. Salesforce will "Archive" activities older than a year and they are not accessible via the API, and hence, the DemandTools.

You can request from salesforce.com that only activities older than 3 years be archived so you will be able to move tasks and events less than 3 years old. You will need to contact salesforce.com technical support to have this done.

UPDATE: All requests for archive date changes are evaluated individually and implementation of the request is not guaranteed. Possible ramifications of changes to the archive period include a possible performance impact on activity related reports and list views for the specific organization. Unarchiving activities will also increase your storage usage.

NEW: Many customers choose to change the archive period temporarily (i.e. 30 days) then run their first round of deduplication. Going forward running"maintenance" dupes (i.e. weekly, monthly etc.), select the "oldest record" as the master. This assumes that all new duplicates will have been created recently and are records that would not have any activities greater than one year old.

How to make an "Unarchive Activity Request" to Salesforce:

Create a case with salesforce.com with a subject of "unarchive activity request"
In the body of the message specify:
- the justification for this request.
- how many years you'd like your activities to remain active (unarchived.)
- if the previously archived records should be unarchived as well.
The request must be made by a user on the account with the System Administrator profile.

All requests for archive date changes are evaluated individually and implementation of the request is not guaranteed. Possible ramifications of changes to the archive period include a possible performance impact on activity related reports and list views for the specific organization.

To retain the proper CreatedDate & CreatedByID field values for objects that need to be cloned vs. reparented, create a case with salesforce.com requesting ability to modify system fields:

There is a feature in Salesforce called "Modifiable System Fields" and is only available when you are creating new records (cannot be used when updating existing records).

The process to do this is as follows:

1. Create a case with salesforce.com with a subject of "Modifiable System Fields Request"
2. In the body of the message specify the justification for this request. Include as MUCH DETAIL as possible. (i.e. migrating from a legacy system and wanting to keep the integrity of the original data, merging data using DT ).
3. The request must be made by a user with the System Administrator profile on the Account.

All requests for are evaluated individually and implementation of the request is not guaranteed.

The Following Additional Options will show up in Screen#3 when "Use Salesforce Merge" is not available, or you manually uncheck the box:

1. Non-Master Objects: Specifies what should be done with the slave records (those marked with a red pin)

Delete - Send the Servant record to the Salesforce Recycle bin. Can be undeleted with in a 30 day period (if the recycle bin does not reach the record size limit).
Prefix - Select which field to prefix and enter the value you would like added

2. Duplicate Campaign Exception: Only applies if merging Leads or Contacts (and it is recommended to not uncheck "Use Salesforce Merge" when merging Leads or Contacts). Only applies to DUPLICATE campaigns (i.e. the same campaign exists on the Master and Slave records)

Use Master: Keep the Campaign Member from the Master Record
Use Most Recent: Keep the Campaign Member that has been most recently modified on all the records

3. Inactive Ownership Exceptions: Used to override some limitations of the API in the areas of reassignment of objects owned by inactive users. In some cases the API will not allow these types of objects to be reparented.

Reassign to master object owner and then reparent
Reassign to current user (the user that is logged into DemandTools) then reparent
Keep ownership (requires a spare Salesforce license). The deduper will reactivate the user, update object owner and move object, then deactivate user.

4. Extra Field Logging: This is available with or without using the Salesforce Merge call, and allows the ability to add one additional field to the DemandTools logfile (in addition to the Salesforce ID of the records being merged)

5. Cloned Custom Objects: The recommendation is to always keep this checked.

Ensures that ALL custom objects are merged, not just referenced ones, ones that truly are beneath the custom object in database hierarchy (we expect very, very rare).