If you want to synchronize contact data between two systems, and one of the two systems differentiates between Leads and Contacts, there are a few things to consider when configuring the plan. We assume a bidirectional synchronization. Data can be entered in all three modules.
The schematic diagram of the infrastructure looks like this:
We call the module in system A Profiles to distinguish it. The modules in system B are called Leads and Contacts.
The data and fields in the modules can look as shown below. The field Name is representative for all fields which should synchronize information about the person. The other fields are needed for technical reasons for synchronization.
System A - Profiles
We need the following fields: ID, Name, Lead_ID, Contact_ID
| ID | Name | Lead_ID | Contact_ID |
|---|---|---|---|
| P1 | John | L1 | C1 |
| P2 | Jane | L2 | C2 |
System B - Leads
We need the following fields: ID, Name, Profile_ID, Converted
| ID | Name | Profile_ID | Converted |
|---|---|---|---|
| L1 | John | P1 | 0 |
| L2 | Jane | P2 | 1 |
System B - Contacts
We need the following fields: ID, Name, Profile_ID, Lead_ID
| ID | Name | Profile_ID | Lead_ID |
|---|---|---|---|
| C2 | Jane | P2 | L2 |
Konfiguration der Pläne
The configuration of the Connections in the plans is similar between Contacts and Leads. The configuration is listed below, as several advanced functionalities are required. For each plan, we distinguish the two different Connections (directions of synchronization). We consider the following configurations:
The mapping of Name : Name is representative for all fields that should be mapped and are not needed for technical functionality.
Plan: Profiles <> Leads
| Profiles -> Leads | Leads -> Profiles | |
|---|---|---|
| Mapping | Name : Name | Name : Name |
| Conditions | Converted (Output) != 1 AND Deleted != 1 | Converted (Input) != 1 AND Deleted != 1 |
| Advanced Options | Backpersist Creation Field: Lead_ID Relation_Identifier: Lead_ID Not Use Relation Store: True |
Backpersist Creation Field: Profile_ID Relation_Identifier: Profile_ID Not Use Relation Store: True |
Plan: Profiles <> Contacts
| Profiles -> Contacts | Contacts-> Profiles | |
|---|---|---|
| Mapping | Name : Name | Name : Name |
| Conditions | Converted (Output) = 1 AND Deleted != 1 | Converted (Input) = 1 AND Deleted != 1 |
| Advanced Options | Backpersist Creation Field: Contact_ID Relation_Identifier: Contact_ID Not Use Relation Store: True |
Backpersist Creation Field: Profile_ID Relation_Identifier: Profile_ID Not Use Relation Store: True |
Mapping
The mapping of Name : Name is representative for all fields that should be mapped and are not needed for technical functionality.
Conditions
The conditions control which of the two plans is active. So you can control to synchronize a record in System A EITHER to Contacts OR Leads in System B. The conditions are mutually exclusive. For each lead that is converted in system B, the corresponding value must be automatically written in the field Converted (in Leads and Contacts), in our example the value 1.
Advanced Options
In the Advanced Options you can specify that no Relation Store is used. The option “Not Use Relation Store” controls this. This is necessary in our case, because the identifiers in the systems must be available in one field each. The fact that a lead and a contact can be assigned both to a person in system A also means that split relations are not possible. We want to be able to seamlessly switch from Lead <> Profile to Contact <> Profile during synchronization. Since both use the ID from System A (Profile_ID), no relation stores can be used.
The relations for both plans are thus mapped as fields in the respective module and look as follows (cf. tables above):
- Profile_ID : Lead_ID
- Profile_ID : Contact_ID
During synchronization, however, the relation is not taken from the Relation Store, but from the systems themselves. Therefore, the “Relation Identifier” function is also set in the Advanced Options. Thus, the Relation Identifier can be overwritten and is now looked up in the systems.
If we were using the Relation Store, when a lead is converted to a contact, we would not be able to map the contact to the corresponding profile in System A. This is why we set the Relation Identifier in the Advanced Options. By leaving the Relation Store out of the equation and looking for the identifier in the module itself, this is possible. The following example illustrates this:
System B - Contacts
| ID | Name | Profile_ID | Lead_ID |
|---|---|---|---|
| C2 | Jane | P2 | L2 |
The contact “Jane” is newly created by converting it as a lead before. If we were to use the Relation Store for the Profiles <> Contacts plan, then the record would be newly created in system A, since no relation to it exists yet (cf. function of the Relation Store). However, if the Profile_ID, i.e. the identifier of the Profiles module from system A, is now stored in the contact, the contact can be assigned to an existing profile in system A. This record already exists in system A due to the former connection to the Profiles module. This is the reason why no Relation Store can be used for the Profiles <> Contacts plan if a conversion has to be considered.
For the Profiles <> Leads plan, no Relation Store is used either. However, this is optional. A relation store could also be used here. However, then the identifier fields for each of the two connections would have to be mapped and synchronized so that they are available in the modules.
Backpersist Creation Field
The backpersist option is used to ensure that when a record is created on one side, the necessary IDs are written to the defined field on the other side. You can read more about this here: Advanced Options.
Weitere Details
Two more details are relevant for the process. Both details must be modeled in system B, usually a CRM system.
1. The field Converted must be set accordingly when converting a lead in system B
For both Leads and Contacts, after a conversion, the Converted field must be filled with an appropriate value that indicates that a conversion has occurred. In our example, the value 0 indicates no conversion, while the value 1 indicates a conversion. Likewise, one could work with Booleans.
2. The ID from system A must be copied from lead to contact in system B when converting
In order for the new relation to be made correctly for a contact to an existing record in system A, the Profile_ID must be transferred during the conversion. The Profile_ID namely refers to the record that was linked to the lead and should now be linked to the newly created contact.