HubSpot und ein zweites System: Welcher Wert gewinnt bei einem Konflikt?

Zwei verbundene Systeme brauchen pro Feld eine Regel, welcher Wert gilt. "Beidseitig synchronisieren" beantwortet diese Frage nicht. Sobald beide Seiten denselben Wert ändern, können fachlich richtige Informationen durch eine technisch erfolgreiche Synchronisation verloren gehen.

Dieser Beitrag zeigt eine eigene Feldmatrix und einen Testablauf. Das Beispiel mit CRM und Auftragsverwaltung ist fiktiv. Die Produktbeschreibung bezieht sich auf HubSpot Data Sync; bei anderen Integrationen und individuell programmierten Schnittstellen muss deren Verhalten separat geprüft werden.

Pro Feld entscheiden, nicht pro System

Ein CRM kann die bestätigte Vertriebszuständigkeit führen, während die Auftragsverwaltung die geprüfte Rechnungsadresse enthält. Es gibt dann kein einziges System, das für alle Felder führend ist. Eine pauschale Vorrangregel erzeugt mindestens auf einer Seite falsche Zuständigkeiten.

Beginne mit der fachlichen Frage: Wer darf diese Information bestätigen? Erst danach werden Richtung und Konfliktbehandlung festgelegt. Ein zuständiger Fachbereich braucht keine direkte Schreibberechtigung auf jede technische Kopie. Er braucht einen nachvollziehbaren Weg, den führenden Wert zu korrigieren.

Der Artikel zu doppelter Datenpflege beschreibt die organisatorische Auswahl. Hier geht es um die konkrete Semantik: welcher Wert wann in welchem System ankommt und wie ein Konflikt erkannt wird.

Eine Feldmatrix mit konkretem Zweck

Die letzte Zeile ist bewusst nicht automatisiert. Wenn beide Systeme unbestätigte Telefonnummern enthalten, löst eine Vorrangregel nur den technischen Konflikt. Sie beweist nicht, welche Nummer stimmt. Der Klärfall bleibt sichtbar, bis eine verlässliche Quelle vorliegt.

Die Matrix enthält zusätzlich die tatsächlichen Feldnamen und Typen. Ein Textfeld für Länder und ein Auswahlfeld mit Ländercodes sind nicht unmittelbar austauschbar. Für die Umwandlung braucht es eine explizite Zuordnung. Nicht abbildbare Werte gehen in eine Fehlerliste und werden nicht still zu einem Standardland.

HubSpot-Konfliktregeln nicht überinterpretieren

Die HubSpot-Dokumentation zu Data Sync beschreibt ein bevorzugtes System für Konflikte und die gewählte Synchronisationsrichtung. Die Konfliktregel hebt die Richtung nicht auf. Ein leerer Wert auf der bevorzugten Seite überschreibt nach dieser Beschreibung nicht einfach den Wert der anderen Seite.

Damit ist "CRM gewinnt immer" zu ungenau. Prüfe für die konkrete Integration unterstützte Objekte, Felder und Richtungen. Auch die erste Synchronisation gehört in den Test: HubSpot beschreibt einen initialen Abgleich beider Systeme. Eine neu gespeicherte Konfiguration kann erneut eine initiale Synchronisation auslösen.

Die Feldmatrix ist deshalb ein Sollbild. Erst der Test zeigt, ob der verwendete Connector es abbildet. Wenn die verfügbare Konfliktregel nur gröber eingestellt werden kann, muss das Modell angepasst oder der Umfang begrenzt werden. Die Dokumentation eines Wunsches ist keine umgesetzte Feldsteuerung.

Einen Konflikt vollständig durchspielen

Im fiktiven Test steht bei Kunde K-18 im CRM eine alte Strasse. In der Auftragsverwaltung liegt eine bestätigte neue Rechnungsadresse. Erwartet wird die Übernahme der neuen Adresse ins CRM. Die Kundenidentität bleibt unverändert, und die Änderung darf keine zweite Firma anlegen.

Danach wird im Testbereich eine abweichende CRM-Adresse eingetragen. Nach dem vorgesehenen Abgleich muss erkennbar sein, ob die führende Quelle wiederhergestellt wird, ein Konflikt erscheint oder die Änderung unzulässig durchgereicht wurde. Nur der erste erfolgreiche Lauf reicht nicht: Der zweite Schritt prüft den tatsächlichen Widerspruch.

Das Wort "leer" benötigt eine eigene Bedeutung. Es kann unbekannt, absichtlich entfernt oder technisch nicht geliefert heissen. Wenn diese Zustände im Connector gleich aussehen, lassen sie sich nicht durch eine Tabellenüberschrift unterscheiden. Ein zusätzliches Löschsignal oder eine manuelle Bearbeitung kann erforderlich sein.

Verzögerungen und konkurrierende Schreiber prüfen

Zwischen Änderung und Übernahme liegt eine Verarbeitung. Prüfe daher den dokumentierten Status und den tatsächlich angekommenen Wert. Ein sofortiger Blick auf die Zielseite kann zu früh sein; ein später passender Wert kann wiederum durch eine andere Automation entstanden sein. Zeitstempel und Herkunft helfen, beide Fälle auseinanderzuhalten.

Suche deshalb auch nach Workflows, Importen und manuellen Änderungen, die dieselben Felder schreiben. Zwei Systeme mit eindeutiger Richtung können trotzdem durch einen dritten Schreiber in einen Kreislauf geraten. Das Workflow-Inventar ergänzt die Feldmatrix um diese Abhängigkeiten.

Ein wiederholtes Überschreiben ist ein Betriebsfehler, selbst wenn jeder einzelne Lauf als erfolgreich erscheint. Die Prüfung umfasst mehrere aufeinanderfolgende Änderungen und den Zustand nach Abschluss aller beteiligten Verarbeitungsschritte. Eine pauschale Wartezeit ersetzt keinen Statusnachweis.

Begrenzter Start und kontrollierte Korrektur

Sichere den betroffenen Zielbestand vor der ersten produktiven Änderung. Starte mit einem fachlich abgegrenzten Umfang, sofern die Integration diese Begrenzung zuverlässig unterstützt. Prüfe die tatsächliche Auswahl anhand der IDs. Ein Filter, der nur Neuanlagen begrenzt, ist kein automatischer Schutz für alle Bestandsänderungen.

Bei Fehlern wird zuerst der schreibende Weg gestoppt oder eingegrenzt. Danach werden betroffene IDs und Änderungen ermittelt. Alte Werte werden nicht pauschal zurückgespielt, wenn inzwischen berechtigte neue Änderungen existieren. Die Rücknahme braucht denselben Identitäts- und Feldvergleich wie die Einführung.

Die Abnahme einer CRM-Automatisierung besteht aus einer umgesetzten Feldmatrix und belegten Testfällen. Für K-18 müssen Kundenidentität, bestätigte Adresse und Änderungsherkunft zusammenpassen. Ein grüner Synchronisationsstatus allein beantwortet diese fachliche Frage nicht.

Quellenprüfung: 5. November 2026. Verlinkte Produktdokumentation belegt die ausdrücklich genannten Funktionen. Methoden, Tabellen und Rechenfälle sind eigene redaktionelle Vorschläge; fiktive Beispiele sind keine Kundenresultate.