HEDA Compatibility Deep Dive / Potential Workarounds

• Multiple Email and Phone fields
  • 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.

More details can be found in the following Validity Community post:  https://community.validity.com/customers/s/article/dupeblocker-issues-with-heda-contact-inserts-not-triggering-the-match-on-insert-action

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).

1. 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 
2. 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.

More details can be found in the following Validity Community post (needs to be updated as I just discovered that they CAN be merged in DemandTools when “Use Salesforce Merge” is unchecked): https://community.validity.com/customers/s/article/Merging-Problems-with-HEDA-Higher-Education-Data-Architecture

• 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.

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:

1. 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
2. Use DemandTools FindId’s to check for matching records, then MassEffect to updates any existing (found) records and insert any new records
   1. 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

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

• 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

• “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.

There are caveats when NOT using the Salesforce merge call:  http://help.validity.com/DemandTools/?pageid=salesforce_merge_-_unchecked