Salesforce Connector: Contact syncing, mapping, merging and duplicate management
Contact Syncing
With the Salesforce integration, the Contact ID is stored alongside the supporter record in Engaging Networks using the Contact ID field, which is populated when Contact information is pushed and pulled.
When Contact information is returned to Engaging Networks, the contact ID is checked first; if a match is found, the supporter record is updated. This is a recent update and is currently specific to the Contact sync.
The contact sync uses 18-digit Contact IDs from Salesforce. When manually importing Contact IDs from Salesforce, please ensure you use the 18-digit format for your supporters' Contact IDs.
Contact Push
Engaging Networks will push supporters who have been altered since the last push every 20 minutes, as long as the record meets Salesforce’s minimum required information to create a Contact record: a Last Name.
Engaging Networks tracks which supporters need syncing using the last-modified timestamp. It then compares Contacts that have been altered after this timestamp against: Contact.engaging__EN_Last_Modified_Date__c.
Contact Pull
For the Contact sync to work effectively, two Flow rules must be configured to allow Engaging Networks to pull Contacts correctly.
Rule 1: EN Push False | This Flow updates the “EN Last Modified Date” field on the Contact to tell Engaging Networks which Contacts have been updated since the last pull. |
Rule 2: "EN Push True" | During the supporter sync from Engaging Networks to Salesforce, we set the EN Push field to “TRUE”. This means these updates won’t trigger the EN Push False workflow rule, thus preventing an "echo” of immediately syncing the contacts back to EN. This rule sets the EN Push value to “FALSE” when it is set to “TRUE,” allowing contacts to requalify for the previous flow. |
Engaging Networks will pull Contacts whose EN Last Modified Date has been modified since the last pull.
A unique addition to the Salesforce sync is that on import, Engaging Networks first utilises the Contact’s ID to check for existing supporters. If a match is found, the supporter will be updated.
Manual syncing before going live
Before going live, ideally, both Engaging Networks and Salesforce are manually synced so that each system is as accurate as possible with the other.
Clean data will produce a smoother integration, and determining which segments will be most active will allow supporters and their transactions to match the right Contacts from the start.
When importing Contacts into Engaging Networks or Supporters into Salesforce, it is recommended that the data be in good health.
It is not required to import all Contacts into Engaging Networks, but consider syncing Contact IDs for those with active recurring donations, active advocates/fundraisers, and those who are emailed.
Examine user flows between both systems to ensure all Contacts/Supporters are mirrored prior to going live. The Engaging Networks sync allows you to ‘Clear’ blank fields coming from Salesforce. You would not want to wipe good data in Engaging Networks when a ‘new Contact’ in Salesforce updates an existing supporter in Engaging Networks.
It is therefore essential to determine which system is most up to date for key data.
Managing Questions:
When Engaging Networks pushes and pulls Contacts, value replacements will occur to support the different methods that both systems use to handle this relationship.
Radio Questions
As Opt-ins question values are either Y or N in Engaging Networks, the following happens in sync:
Contacts Pushed | BLANK is replaced with FALSE |
Contacts Pulled | FALSE is replaced with N |
Checkbox fields on the Contact
In Engaging Networks, you can submit any question value, whereas Salesforce is stricter and requires Checkbox values to be TRUE, FALSE, 1, or 0. Therefore, if your organisation plans to use Checkbox fields in the Contact sync, the corresponding fields in Engaging Networks must be set to TRUE or FALSE.
It is recommended that, for questions, TRUE or FALSE be stored in Engaging Networks, and that, for supporter-facing fields, checkboxes submit TRUE or FALSE. Using different values will affect the account user’s queries, as they could have supporters with different values.
Contacts Pushed | BLANK is replaced with FALSE 1, y, Y, true and TRUE are replaced with TRUE Any other value is replaced with FALSE |
Contacts Pulled | Nothing is replaced. We respect the value Salesforce returns. |
Common Errors
| The supporter in Engaging Networks has an invalid ID stored in the Contact ID. Clear out the Contact Id via Lookup Supporters or replace it with a valid ID from Salesforce. |
| For initial integrations, be sure that ‘active’ Contact segments are imported into Engaging Networks prior to launch. This will reduce the need for Engaging Networks to create new Contacts. |
Duplicate Management
Engaging Networks utilizes Salesforce’s Bulk API to upsert supporters as Contacts.
There are two options for how Engaging Networks finds the respective Contacts, configured under Sync Settings: ‘Fuzzy Matching’ or ‘Leverage Salesforce’.
If a suitable match is found, the ID will be copied to the Contact ID, and the supporter record will be eligible for re-push in the next Contact push.
If you have additional Duplicate Rules configured in your Salesforce org (for example, matching rules that look at Phone Number or Street Address), these rules can cause problems for the Contact Sync, which supports only First Name + Last Name + Email.
In this situation, the Salesforce Administrator may choose to set:
Any additional duplicate rules to “Report” instead of “Alert + Report”
Conditions on those duplicate rules using the “Current User” filter, so the rules do not apply to the EN integration user
These settings allow Engaging Networks to look up Contacts on receiving the following error examples:
FIELD_CUSTOM_VALIDATION_EXCEPTION:Failed to create Account for Contact Raya Tester. Duplicate Alert:-FIELD_CUSTOM_VALIDATION_EXCEPTION:Failed to create Account for Contact Jim Tester. Use one of these records?:--FIELD_CUSTOM_VALIDATION_EXCEPTION:A record with this email address already exists.:Email --
For initial integrations, be sure that ‘active’ Contact segments are imported into Engaging Networks prior to launch. This will reduce the need for Engaging Networks to create new Contacts.
Managing multiple email addresses
In Engaging Networks, the unique identifier for supporters is their email address. Currently, our integration model maintains a one-to-one mapping between Supporters and Contacts.
Supporting a single Contact with multiple email addresses linked to different supporters in Engaging Networks isn’t feasible, as the Contact ID serves as a unique identifier within the Engaging Networks Salesforce sync process. This ensures that updates to the Email Address on the Contact are reflected in Engaging Networks.
Page Processing Behaviour Setting
If your organisation stores multiple email addresses on a Contact, Engaging Networks can support up to two if you enable the following setting:
|  |
|  |
Enabling this setting means the system will check during page processing whether a supporter’s email address exists in either the primary or secondary email address field; if a match is found, no supporter record will be created, and the existing supporter record will be retained.
The email address used in the submission will receive the auto-responder.
In Salesforce, the Contact ID will remain unchanged, and a new Contact will not be created, ensuring that the Contact retains both email addresses.
Merging Records:
Automatic merging to Engaging Networks from Salesforce can be facilitated by enabling the 'Reflect merges done in Salesforce' setting under Sync Settings.
Please note that manual merging of up to 2 Contacts is currently supported, and your account must be running a package version higher than 1.32. Merges made in Engaging Networks will not be reflected, as Salesforce is considered the database of record.
For manual merges outside this setting, it's advisable to first merge supporters in Engaging Networks, then merge the corresponding Contacts in Salesforce. It's crucial to ensure that the correct Contact Id and Supporter Id is retained on the Engaging Networks supporter's record.
When a contact is merged in Salesforce and the Contact has a value present in EN_Supporter_Id__c, a ‘Merge Audit’ record will be created that has the following details: |
|
When completing a merge in Salesforce, please ensure that the EN Supporter ID associated with the retained Contact ID is also retained.
With the setting enabled, after Contact B is merged into Contact A in Salesforce, a job checks for merges made since the last check and then merges Supporter B with Supporter A.