Need to ensure the correct/desired ones are selected for matching
The Standard Email and Phone fields will be auto-populated based on the “Preferred” email/phone
Deployed Account Scenario with Match on Insert Action: “Do Not Insert”
Inserting a Contact that results in a duplicate Account being created
Will get an unformatted message in red (not the typical formatted blocking message) and the “Bypass Block” button will NOT be available.
A validation rule is preventing the record from being processed. This could be from this record, or a related record being updated. VALIDATION MESSAGE: <!-- DupeBlocker blocked this action - duplicates found. --> <div style="padding
Both the Account and Contact insert will be blocked as a result
Insert Action will not trigger for new Contacts NOT added to an already existing Administrative Account
In the HEDA model, a Contact is typically added without specifying an Account. As part of the Contact insert an “Administrative” Account is automatically inserted and the Contact is associated with that new Account. Since DupeBlocker will only fire for the first object created in the same Apex Batch, it will not trigger for the Contact, since the Account is created first.
Whatever action (block, redirect, report duplicate, or auto-merge) WILL NOT trigger and the duplicate will not be detected.
Merging Problems (NOTE: These are not unique to CRMfusion tools, same issues exist trying to merge the SF User Interface)
Cannot merge Contacts if the non-master record has Account Affiliation or Relationship sub-objects (perhaps other specific sub-objects as well)
The Salesforce Apex merge call does not seem to support merging all sub-objects onto the master record.
HEDA triggers prevent contacts from being deleted if they contain the above sub-objects (the non-master cannot be deleted to complete the merge).
WORKAROUNDS:
Merge the duplicates using DemandTools with “Use Salesforce Merge” unchecked. Can use the “Select from DupeBlocker” tab to pull in any existing DupeBlocker Warnings and merge them. There are caveats when NOT using the Salesforce merge call: http://help.validity.com/DemandTools/?pageid=salesforce_merge_-_unchecked
Turn off the HEDA triggers that block the deletion of the Contacts with sub objects. This could result in data loss, so is not recommended.
When a Contact merge is successful the “Administrative Account” is not deleted by default
There is an option in HEDA Settings to allow the “Administrative Account” to be automatically deleted if there are no Contacts associated with it.
HEDA: PeopleImport
Feature
Issue
General
PeopleImport is designed to work with the standard B2B Salesforce model. When importing Contacts an Account Name needs to be mapped so that an Account can be created to associate the new Contact with.
Since the HEDA model automatically creates an Account when inserting a new Contact, HEDA users would typically NOT have an Account Name in their input file, and therefore would not be able to use PeopleImport to import new Contacts.
WORKAROUNDS:
Users could update their input file to include a column with the Administrative Account name that would have been used if the Account were auto-created, i.e. {Contact Last Name} Administrative Account. This could be done with a simple formula in excel that concatenates the last name column with the text “ Administrative Account”. That column could then be mapped to the Account Name field which would fulfill the mapping requirement in PeopleImport
Use DemandTools FindId’s to check for matching records, then MassEffect to updates any existing (found) records and insert any new records
When importing in MassEffect nothing will need to be mapped to the AccountID field as the Account will be auto-created when the Contact is inserted.
Auto Mapping and Address Fields
Any columns with the words city or country in them will be auto mapped to the equivalent Mailing or Billing address fields (i.e. Mailing City, Mailing Country). As a result, columns called “Ethnicity” or “County of Origin” (custom fields in HEDA) will auto map to the address fields (along with the correct Ethnicity and Country of Origin fields)
If users select to auto-map their fields (and those columns exist) users will need to manually remove the mapping to City and Country fields
WORKAROUND:
Have any actual City, Country columns in the input file BEFORE any Ethnicity or Country of Origin columns
HEDA: DemandTools
HEDA users will need to run their own tests with their configuration to determine what works and what does not, especially when it comes to merging.
Module
Issue
All Maintenance Modules
Should work
When inserting Contacts via MassEffect and AccountID does not need to be specified as the Account will be auto-created when the Contact is created
Lead Conversion
Any Leads converted to NEW Contacts AND Accounts will be converted to “traditional” Contacts/Accounts (i.e. the new contact will be on an account that that was created from the “Company” information in the Lead, vs. creating an “Administrative Account” for each new contact
Can be used to match Leads to existing Contacts and Accounts
Find/Report ID's
Should work
Single Table Dedupe
“Use Salesforce Merge” will NOT work when merging Contacts when a non-master record has Account Affiliation or Relationship sub-objects (perhaps other specific sub-objects as well)
“Use Salesforce Merge” may work when merging Accounts depending on the type of Account and sub-objects associated with it
Merging Contacts with OUR merge code in DemandTools seems to work
Need to ensure that all HEDA sub-objects are checked in “Merge Objects” option on the right
When a Contact merge is successful the “Administrative Account” is not deleted by default
There is an option in HEDA Settings to allow the “Administrative Account” to be automatically deleted if there are no Contacts associated with it.
Merging Accounts with OUR merge code in DemandTools works in some cases but not in others
Need to ensure that all HEDA sub-objects are checked in “Merge Objects” option on the right
HEDA triggers could prevent some of the sub-objects from being re-parented which will cause the merge to fail, some error encountered:
Update,,,,," Message: hed.TDTM_Affiliation: execution of AfterUpdate<LF><LF>caused by: System.NullPointerException: Attempt to de-reference a null object
Delete,,,,," Message: Record cannot be deleted because children records exist. Delete children first. Status code: 98"
• Even when it “works” there can still be unexpected issues. The model is too complex to try and document all the relationships/customizations that could cause it to fail, possibly result in data loss, and/or other unexpected results.
We are excited to announce the latest in customer training for the Everest Platform. Starting June 5, we will begin offering daily, 30-minute training sessions on the core modules of the Everest Platform detailed below. Led by our email experts, each of these short sessions will provide an overview of the module’s capabilities, allowing you to ask questions and ensuring you get the most from your Everest subscription. Whether you are new to Everest, or an experienced user who isn’t taking advantage of all it has to offer and would like to learn more, this training series is for you!