NPSP 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 ONLY if the associated workflow rule is activated (not activated by default)
  • The potential duplicate objects will only show the standard email and phone field, so they will show blanks if those fields are not auto-populated.

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 (the error is very long, below is the first part):
  • Failed to create Account for Contact Laurie Hanlon. <!-- DupeBlocker blocked this action - duplicates found. -->
• Both the Account and Contact insert will be blocked as a result

Insert Action will not trigger for new Contacts

As part of the Contact insert a “Household” 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. It also seems that even when you add a new Contact to an EXISTING Household Account DupeBlocker will still not fire for the Contact as an update is done for the Account (Number of Household Members and Formal/Informal Greeting fields updated).

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

DupeBlocker issues with Non-Profit Starter Pack: Contact inserts not triggering the "Match on Insert Action"

Merging Contacts from a Warning

When merging Contacts, when the non-master Contact is deleted the Account the Contact was associated with will be renamed “Anonymous Household” vs. being deleted.

• The same thing will happen when merging directly in the Salesforce User Interface (Salesforce’s UI Merge)

This DOES not happen however when using the custom NPSP merge option only available in Lightning

POSSIBLE WORKAROUND:

Simply look for the Anonymous Household Account after the merge is complete, should see it at the top of the list of recent items, then manually delete it.

Auto-Merging Accounts

NPSP trigger is causing Auto-merge to fail with the following error for Household Accounts created automatically when a Contact is inserted.  Even if this did work, it could result in the Contact NOT being created.

*** Exception Message: Merge failed. First exception on row 0 with id 001f200001XX3q1AAD; first error: DELETE_FAILED, npsp.TDTM_Account: execution of AfterDelete

caused by: System.DmlException: Update failed. First exception on row 0 with id 001f200001XX3q1AAD; first error:

SELF_REFERENCE_FROM_TRIGGER, Object 001f200001XX3q1AAD is currently in a merge operation, therefore a trigger can not update it.: []

POSSIBLE WORKAROUND:

Will need to change the “Match on Insert” action to Report Duplicate.  Could also change to “Do Not Insert” but then will get the unformatted block message as noted in item #2 above.

NOTE:  If wanting auto-merge to work for NON Household accounts could add an object filter where Account Name “does not end with” household.  This would stop the errors from being sent when the Auto-Merge fails for Household Accounts.

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.  The “Household” Account recordtype will also need to be mapped, unless it is the users default record type on their profile.

Since the NPSP model automatically creates an Account when inserting a new Contact, NPSP users would typically NOT have an Account Name or recordtypeid in their input file, and therefore would not be able to use PeopleImport to import new Contacts.

POSSIBLE WORKAROUNDS:

1. Users could update their input file to include a column with the Household name that would have been used if the Account were auto-created, i.e. {Contact Last Name} Household.  This could be done with a simple formula in excel that concatenates the last name column with the text “ Household”.  That column could then be mapped to the Account Name field which would fulfill the mapping requirement in PeopleImport.
   1. As noted above, users will need to ensure the correct recordtype is used for new Account.
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.

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

• Can be used to convert Leads to existing Contacts and Accounts, although users may want to use the NPSP Convert option for this as well (see next bullet and supporting document).
• 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 a “Household Account” for each new contact
  • NPSP does have its own Lead Conversion button that can be used to convert Leads to NEW Contacts and Household Accounts.
  • More information on that option can be found in the following Power of Us help video.

Note:  If opting to NOT use Lead Conversion to process conversions it can still be used to find matches then the results can be exported to a file so that the user knows which records to convert in the UI with the NPSP custom convert option.

When merging Contacts, when the non-master Contact is deleted the Account the Contact was associated with will be renamed “Anonymous Household” vs. being deleted.

• • The same thing will happen when merging directly in the Salesforce User Interface (Salesforce’s UI Merge)
  • This DOES not happen however when using the custom NPSP merge option only available in Lightning

NOTE:  Donations are moved from any non-master contacts to the master contact, so the Anonymous Household created after merging WILL NOT contain any donations and can be deleted.  Anonymous Households are also created when Contacts are directly deleted that contain donations.  Attempts to delete an Anonymous Household that contains donations will be blocked by Salesforce.

POSSIBLE WORKAROUNDS:

1. After completing the merge in DemandTools simply use MassEffect to export any Accounts with the name “Anonymous Household” then read the exported file back into MassEffect and delete them.
2. In the Single Table Dedupe Merge scenario, on the right in Options -> Extra Field logging select the “npsp_HHId__c” field (the Household Id field) to be logged.  The “MergeRecord” file created in the DemandToolsData\Logfiles directory when the merge is completed will have all the non-master HHid fields in the column Merged_npsp__HHId__c.
   1. Use this file in MassEffect to delete the Anonymous Accounts (map the column Merged_npsp__HHId__c to the Id field in the Account)

Single Table Dedupe Field Rules on Email or Phone Fields

Users may get unexpected results when using Field Rules to update the standard email or phone field due to Workflows that auto-populate these fields based on the “Preferred Email”.

• If the workflows rules are deactivated then all should work as per the field rule setting (not activated by default when the template is installed)
• If unexpected results are occurring check for which workflow rules are active which could be overwriting the expected value per the field rule criteria