Schnittstellen

Marketing-Schnittstellen

So planen Sie Marketing-Schnittstellen anhand von Übergabefall, Datenvertrag, Anbindungsweg und überprüfbarem Ergebnis im Zielsystem.

Marketing-Schnittstellen verbinden Systeme für einen bestimmten Vorgang: Ein Ereignis in der Quelle soll im Ziel einen passenden Datensatz oder eine passende Beziehung anlegen oder ändern. Beschreiben Sie diesen Vorgang und den erwarteten Zielzustand, bevor Sie eine Anbindung auswählen.

Den Übergabefall festlegen

Eine brauchbare Beschreibung lautet: „Nach Ereignis X in System A soll System B Datensatz Y mit Information Z ändern.“ Ergänzen Sie, wann keine Änderung erfolgen soll. Eine Formularübermittlung kann etwa einen Kontakt aktualisieren, ohne zugleich eine Kampagnenmitgliedschaft oder einen Versand auszulösen.

Unterscheiden Sie dabei Stammdaten, einzelne Ereignisse und Beziehungen zwischen Datensätzen. Ein Feld „letzte Kampagne“ kann für eine Ansicht nützlich sein. Es bildet jedoch nicht mehrere Kampagnenzugehörigkeiten ab.

Einen Datenvertrag erstellen

Frage / Benötigte Festlegung

Welcher Vorgang?
Auslösendes Ereignis und Kennung für dessen Wiedererkennung
Welche Person?
Regel zum Finden oder Anlegen des Zieldatensatzes
Welche Daten?
Zielattribute, Typen und erlaubte Werte
Welche Änderung?
Richtung, führendes System und Umgang mit leeren oder widersprüchlichen Werten
Welcher Erfolg?
Erwarteter Zustand im Zielsystem
Welcher Fehler?
Sichtbarer Zustand und Zuständigkeit bei unklaren Fällen

Produktregeln können diese Festlegungen einschränken. Bei der HubSpot-Salesforce-Integration bestimmen Synchronisierungseinstellungen, ob Aktualisierungen zwischen den Systemen übertragen werden. Prüfen Sie daher die geltende Regel und die vorhandenen Daten für jedes betroffene Feld.

Feldtypen und Zuordnungen prüfen

Bei der HubSpot-Salesforce-Integration werden Dropdown- und Radio-Auswahlfelder Salesforce-Picklists oder Referenzfeldern zugeordnet. Mehrfachauswahl kann auf Multipicklists, einzelne Kontrollkästchen auf boolesche Felder und Zahlen auf Double- oder Integer-Felder abgebildet werden.

Auch Text- und Datumsfelder haben festgelegte Gegenstücke: Einzeiliger Text kann auf String- oder Textarea-Felder, mehrzeiliger Text auf Textarea sowie ein Datumsfeld auf Date- oder DateTime-Felder synchronisiert werden.

Ein Feld sollte nicht mehrfach auf Salesforce-Felder abgebildet werden und keine bestehende Standardzuordnung überlappen. HubSpot warnt vor solchen Duplikaten, weil sie mehrere Felder aktualisieren, Werte überschreiben, unbeabsichtigte Zuordnungen auslösen oder Synchronisierungsschleifen erzeugen können.

Für Unternehmens- und Deal-Felder setzt die Einrichtung einer Zuordnung voraus, dass die Objektsynchronisierung zwischen HubSpot und Salesforce eingeschaltet ist. Eine Kontakt-Eigenschaft wie „Job title“ kann beispielsweise einem Lead- oder Kontaktfeld in Salesforce zugeordnet werden.

Den Übertragungsweg wählen

Eine native Anbindung kommt infrage, wenn sie die benötigten Objekte, die Änderungsrichtung und die Konfliktregel unterstützt. Prüfen Sie zusätzlich Berechtigungen und Tarifvoraussetzungen. Bei HubSpot und Salesforce müssen zugeordnete Feldtypen kompatibel sein; benutzerdefinierte HubSpot-Eigenschaften vom Typ „Benutzer“ lassen sich über diese Feldzuordnung nicht auf Salesforce-Felder abbilden.

Eine Integrationsschicht kann mehrere Quellen vereinheitlichen oder Werte vor dem Schreiben prüfen. Sie bringt eigene Zugangsdaten, Fehlerzustände und Betriebsaufgaben mit.

Eine eigene API-Anbindung ist eine weitere Möglichkeit, wenn die verfügbaren Wege den Übergabefall nicht abbilden. Dann müssen Authentifizierung, Änderungen an der API und wiederholte oder unklare Übertragungen selbst betreut werden.

Vergleich der Übertragungsweg-Optionen

Native Anbindung (z. B. HubSpot ↔ Salesforce)
Einfache Einrichtung, vorgegebene Synchronisierungsregeln, aber eingeschränkte Flexibilität
Integrationsschicht (z. B. MuleSoft, Zapier)
Zentralisierte Verarbeitung mehrerer Quellen, Vorverarbeitung von Daten, aber zusätzliche Wartungsaufwand
Eigene API-Anbindung
Maximale Flexibilität, aber hoher Betriebsaufwand für Authentifizierung, Fehlerbehandlung und Monitoring

Betriebsgrenzen der Anbindung einplanen

Bei Power Automate hängen die Anforderungsgrenzen eines Flows von dessen Leistungsprofil ab; dieses richtet sich nach dem verwendeten Lizenzplan. Ein Vergleich der Anbindungswege sollte deshalb nicht nur die Connector-Funktion, sondern auch das erwartete Volumen und den passenden Plan berücksichtigen.

Für eine einzelne Flow-Definition nennt Microsoft eine Grenze von höchstens 500 Aktionen. Flows mit vielen Aktionen können daher eine Entwurfsgrenze erreichen, auch wenn der fachliche Übergabefall grundsätzlich unterstützt wird.

Ein Cloud-Flow verwendet den Plan seines Eigentümers. Verlässt der ursprüngliche Eigentümer die Organisation, fällt der Flow laut Microsoft auf das niedrige Leistungsprofil zurück; Zuständigkeit für Betrieb und Eigentümerschaft gehören deshalb zur technischen Planung.

Prüfen Sie für jedes Feld, ob die gewählte Synchronisierungsrichtung zum fachlich führenden System passt, statt eine globale Annahme auf alle Felder zu übertragen.

Betriebsgrenzen bei Microsoft Power Automate

Max. Aktionen pro Flow
500
Leistungsprofil beeinflusst durch Lizenzplan
Ja
Rückfall auf niedriges Profil bei Eigentümerwechsel
Ja (laut Microsoft)

Eingang und Ergebnis prüfen

Bei Webhooks muss die zum Anbieter passende Echtheitsprüfung vor einer CRM-Änderung erfolgen. Prüfen Sie danach Ereignistyp und benötigte Werte. GitHub und HubSpot dokumentieren unterschiedliche Signaturverfahren; deren Regeln sind nicht austauschbar.

Legen Sie für einen kleinen Übergabefall die erwarteten Ergebnisse bei einem neuen Kontakt, einem vorhandenen Kontakt, fehlenden Angaben und einer erneuten Zustellung fest. Kontrollieren Sie den Datensatz und gegebenenfalls seine Beziehung im Zielsystem. Ein angenommener HTTP-Aufruf allein belegt den fachlichen Zielzustand nicht.

Abnahmekriterien für die Übergabe festlegen

Legen Sie je Testfall fest, welche Datensätze und Beziehungen im Zielsystem vorhanden sein müssen und welche Werte sie enthalten sollen. Eine erneute Zustellung darf dabei nicht zu zusätzlichen, unbeabsichtigten Datensätzen oder Beziehungen führen.

Definieren Sie außerdem, woran ein fehlgeschlagener oder unvollständiger Übergang erkennbar ist und wer ihn nachverfolgt.

Prüfliste vor der Implementierung einer Schnittstelle

  • Erwartete Datensätze im Zielsystem vorhanden?Ja / Nein
  • Beziehungen korrekt angelegt?Ja / Nein
  • Keine doppelten oder unbeabsichtigten Datensätze entstanden?Ja / Nein
  • Fehlerfälle dokumentiert und zuständigkeitsgeklärt?Ja / Nein
  • Eingang überprüft (z. B. Webhook-Signatur validiert)?Ja / Nein

In diesem Leitfaden

  1. Formularfelder auf Kontaktdatensätze abbildenLegen Sie für Formularfelder Zielattribute, erlaubte Werte und Änderungsregeln fest und prüfen Sie das Ergebnis am Kontaktdatensatz.
  2. Kampagnenzugehörigkeit an das CRM übergeben und prüfenKlären Sie Person, Zielkampagne, Auslöser und Mitgliedsstatus, bevor eine Marketingaktion eine CRM-Kampagnenzugehörigkeit erzeugt.
  3. Webhook-Daten vor der Verarbeitung prüfenSo prüfen Sie Herkunft, Ereignistyp, Pflichtwerte und wiederholte Zustellungen, bevor ein Webhook Daten im CRM ändert.
  4. Native Anbindungen mit einer Integrationsschicht vergleichenVergleichen Sie native Anbindungen und Integrationsschichten anhand von Datenmodell, Feldregeln, Ausnahmen, Betrieb und Zielzustand.

Mehr aus Schnittstellen

Schnittstellen

Kampagnenzugehörigkeit an das CRM übergeben und prüfen

Klären Sie Person, Zielkampagne, Auslöser und Mitgliedsstatus, bevor eine Marketingaktion eine CRM-Kampagnenzugehörigkeit erzeugt.