Known Limitations of the STD Deduper
Tuesday, August 15, 2006
Is the merge process perfect? ..... Known Limitations in the 1.7 STD Deduper
Contact De-Duping: Self-Service Users
When a servant contact is merged into a master contact and the servant contains a self service user the SSU will be inactivated on the servant contact and will be recreated on the master contact. You will lose all login information for the SSU and will have to send the user a new password as this is not moved in the creation of the SSU.
Additionally, if the servant was also a "Super User" you will need to manually re-activate this status on the master contact.
Contact De-Duping: Campaign Members Status Dates
When duping contacts and opt'ing to use the "Duplicate Campaign Exception - Use Most Recent", if the most recent record is on the slave, when it is cloned to the master the "Last Modified Date" (which is also the status date) will become the date of the merge. If the most recent record is on the master, we do not touch the record, so the original date stays intact.
This will happen EVEN if you have had "Modify System Fields" turned on by salesforce.com. The only workaround is to create a custom object to track campaign history. There are some 3rd party vendors that have developed software that does this for you. Search the SF AppExchange for a current list.
Account De_Duping: Active Contracts
The salesforce.com API does not allow the re-parenting of "Active" contracts. Therefore when duping account records DemandTools CANNOT merge "active" contracts from slave accounts to the selected master account.
As a workaround we have added a master rule for "Most Active Contracts", so you can set the master based on active contracts. When you run your Single Table De-dupe on your accounts you will receive errors if there are still contracts that could not be re-parented. In the log file, it will indicate which slave accounts had active contracts and that it was unable to delete these slave records. You can then select these using salesforce.com's merge feature and merge them one at a time.
Use Conditions: Owner Role
Using the "Owner Role" in your "Use Conditions" for selecting which objects to check for duplicates will physically convert the Owner Role to the individual user id's.
If you update the members of a Role, you should re-do the "Use Conditions" (clear and re-add) so the correct user id's will be inserted.
Not perfect ... but pretty close to it.
posted by Mark Esdale @ 11:57 AM,
