Wenn du zwischen zwei Systemen Personendaten synchronisieren möchtest und eines der beiden Systeme zwischen Leads und Contacts unterscheidet, musst du bei der Planeinrichtung einige Dinge beachten. Wir nehmen eine bidirektionale Synchronisierung an. Es können Daten in allen drei Modulen eingetragen werden.
Das schematische Diagramm der Infrastruktur sieht folgendermaßen aus:
Das Modul in System A nennen wir zur Unterscheidung Profiles. Die Module in System B benennen wir Leads und Contacts.
Die Daten und Felder in den Modulen können aussehen wie unten dargestellt. Das Feld Name steht stellvertretend für alle Felder, welche Informationen über die Person synchronisieren sollen. Die anderen Felder werden aus technischen Gründen für die Synchronisierung benötigt.
System A - Profiles
Wir benötigen folgende Felder: ID, Name, Lead_ID, Contact_ID
| ID | Name | Lead_ID | Contact_ID |
|---|---|---|---|
| P1 | John | L1 | C1 |
| P2 | Jane | L2 | C2 |
System B - Leads
Wir benötigen folgende Felder: ID, Name, Profile_ID, Converted
| ID | Name | Profile_ID | Converted |
|---|---|---|---|
| L1 | John | P1 | 0 |
| L2 | Jane | P2 | 1 |
System B - Contacts
Wir benötigen folgende Felder: ID, Name, Profile_ID, Lead_ID
| ID | Name | Profile_ID | Lead_ID |
|---|---|---|---|
| C2 | Jane | P2 | L2 |
Konfiguration der Pläne
Die Konfiguration der Connections in den Plänen gleicht sich zwischen Contacts und Leads. Die Konfiguration wird im folgenden aufgeschlüsselt, da mehrere fortgeschrittene Funktionalitäten benötigt werden. Pro Plan unterscheiden wir jeweils die zwei unterschiedlichen Connections (Richtungen der Synchronisation). Wir betrachten folgende Konfigurationen:
Das Mapping von Name : Name steht stellvertretend für alle Felder, die gemappt werden sollen und nicht für die technische Funktionalität benötigt werden.
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
Das Mapping von Name : Name steht stellvertretend für alle Felder, die gemappt werden sollen und nicht für die technische Funktionalität benötigt werden.
Conditions
Die Conditions steuern, welcher der beiden Pläne aktiv ist. So kann gesteuert werden, dass zu einem Datensatz in System A ENTWEDER aus Contacts ODER Leads in System B synchronisiert wird. Die Bedingungen sind sich gegenseitig ausschließend. Für jeden Lead, der in System B konvertiert wird, muss automatisch der entsprechende Wert in das Feld Converted geschrieben werden (in Leads und Contacts), in unserem Beispiel der Wert 1.
Advanced Options
In den Advanced Options wird geregelt, dass kein Relation Store verwendet wird. Die Option „Not Use Relation Store“ legt dies fest. Das ist in diesem Falle notwendig, da die Identifier in den Systemen jeweils in einem Feld vorhanden sein müssen. Dadurch, dass einer Person in System A ein Lead und ein Kontakt zugeordnet sein können, sind auch geteilte Relationen nicht möglich. Wir möchten, dass nahtlos bei der Synchronisierung von Lead <> Profile zu Contact <> Profile gewechselt werden kann. Da beide die ID aus System A (Profile_ID) verwenden, können keine Relation Stores benutzt werden.
Die Relationen für beide Pläne sind somit als Felder im jeweiligen Modul abgebildet und sehen wie folgt aus (vgl. Tabellen oben):
- Profile_ID : Lead_ID
- Profile_ID : Contact_ID
Bei der Synchronisierung wird die Relation allerdings nicht aus dem Relation Store gezogen, sondern aus den Systemen selbst. Daher wird auch die Funktion „Relation Identifier“ in den Advanced Options gesetzt. Somit kann der Relation Identifier überschrieben werden und wird nun in den Systemen nachgeschaut.
Würden wir den Relation Store verwenden, könnten wir, wenn ein Lead zu einem Kontakt konvertiert wird, nicht die Zuordnung zum entsprechenden Profile in System A vornehmen. Dadurch, dass wir den Relation Store außen vor lassen und im Modul selbst nach dem Identifier suchen, ist dies möglich. Folgendes Beispiel verdeutlicht dies:
System B - Contacts
| ID | Name | Profile_ID | Lead_ID |
|---|---|---|---|
| C2 | Jane | P2 | L2 |
Der Kontakt „Jane“ wird neu angelegt, indem er als Lead zuvor konvertiert wurde. Wenn wir nun den Relation Store für den Plan Profiles <> Contacts verwenden würden, dann würde der Datensatz in System A neu angelegt werden, da noch keine Relation dazu vorhanden ist (vgl. Funktion des Relation Stores). Wenn im Kontakt aber nun die Profile_ID, sprich der Identifier des Moduls Profiles aus System A steht, kann eine Zuordnung des Kontakts zu einem bestehenden Datensatz in System A erfolgen. Dieser existiert bereits durch die ehemalige Verbindung zum Lead, aus dem der neue Kontakt entstanden ist. Das ist der Grund, wieso kein Relation Store für den Plan Profiles <> Contacts verwendet werden kann, wenn eine Konvertierung berücksichtigt werden soll.
Für den Plan Profiles <> Leads wird ebenso kein Relation Store verwendet. Das ist jedoch optional. Hier könnte auch ein Relation Store verwendet werden. Dann müssten jedoch die Felder der Identifier für jede der beiden Connections gemappt und synchronisiert werden, sodass diese in den Modulen verfügbar sind.
Backpersist Creation Field
Die Option backpersist wird verwendet, damit sichergestellt werden kann, dass die notwendigen IDs beim Erstellen eines Datensatzes auf einer Seite auch daraufhin in das definierte Feld auf der anderen Seite geschrieben werden. Mehr dazu kannst du hier nachlesen: Advanced Options.
Weitere Details
Zwei weitere Details sind für den Prozess relevant. Beide Details müssen in System B, zumeist in CRM-System, abgebildet werden.
1. Das Feld Converted muss bei Konvertierung in System B gesetzt werden
Sowohl bei Leads als auch Contacts muss nach einer Konvertierung das Feld Converted mit einem entsprechenden Wert versehen werden, der indiziert, dass konvertiert wurde. In unserem Beispiel indiziert der Wert 0 keine Konvertierung, während der Wert 1 eine Konvertierung bedeutet. Gleichfalls könnte man mit Booleans arbeiten.
2. Die ID aus System A muss bei der Konvertierung in System B übernommen werden
Damit die neue Zuordnung bei einem Kontakt zu einem bestehenden Datensatz in System A korrekt vorgenommen werden kann, muss bei der Konvertierung die Profile_ID übernommen werden. Diese referenziert nämlich auf den entsprechenden Datensatz, dem der Lead, aus dem der Kontakt entstanden ist, zugeordnet ist.