Help Center

Du hast noch keinen HubEngine Account?

Du möchtest einen HubEngine Plan konfigurieren?

Marini Systems Trainings - Businesswoman during presentation in board room.

Academy

Erlerne gefragte Skills im Bereich Datenintegration und -management.

Typ: FAQ
Komponente: HubEngine
Bereich: Allgemein

Wie richte ich Pläne für eine Lead-Contact-Conversion ein?

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:

Technologies / Integration Workflows
2 Systems bidirectional orchestration

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.

Weitere Dokumente aus den Bereichen

Bereich: Allgemein

Deine Frage - Wir antworten gerne

Hast du bereits geprüft, ob deine Frage nicht schon beantwortet wurde?

Häufige Fragen und Antworten, die sich im Laufe der Projekte ergeben, veröffentlichen wir im Help Center. Die Wahrscheinlichkeit, dass die von dir gesuchten Informationen dort zu finden sind, ist hoch. Falls deine Fragen dort noch nicht beantwortet wurden, nehmen wir uns sehr gerne die Zeit für die Beantwortung. Sende uns dazu ein Support Ticket.

Menü