August 2026: HubSpot baut CRM-Automatisierung aus

Der Kontext: HubSpot wird zur Integrationsplattform

Wer HubSpot vor fünf Jahren aufgesetzt hat, kennt das Bild: eine Marketing-Suite mit CRM-Kern, in der Individualisierung meist über Workflows und gelegentlich über die API lief. Der August-2026-Rollup zeigt, wie weit sich das Bild seither verschoben hat. HubSpot baut nicht mehr nur Features für Marketer, sondern Infrastruktur für Teams, die Daten aus mehreren Systemen zusammenführen und Prozesse über Objektgrenzen hinweg automatisieren müssen. Drei Änderungen aus dem Rollup verdienen genauere Betrachtung, weil sie exemplarisch für diese Entwicklung stehen.

Webhook-Datenquellen für Data Studio

Bislang bedeutete "Daten von extern nach HubSpot bringen" in vielen Projekten: ein Middleware-Tool wie Zapier, Make oder eine selbst gebaute Lambda-Funktion, die per API Datensätze anlegt oder aktualisiert. Mit Webhook-Datenquellen für Data Studio verschiebt sich ein Teil dieser Logik direkt in HubSpot. Externe Systeme können Events per Webhook senden, die dann als Datenquelle für Reporting und Analysen zur Verfügung stehen, ohne dass dafür eine dedizierte Integration mit eigenem Hosting, Monitoring und Fehlerbehandlung aufgebaut werden muss.

Für Teams mit begrenztem Entwicklungsbudget ist das relevant: Ein Anwendungsfall, der bisher einen externen Service erforderte, lässt sich jetzt teilweise nativ abbilden. Das reduziert nicht nur Entwicklungszeit, sondern auch die Anzahl der Systeme, die im Betrieb überwacht werden müssen. Wichtig für die Praxis: Native Lösungen sind nicht automatisch die bessere Wahl. Wer bereits eine funktionierende Middleware-Schicht betreibt, sollte prüfen, ob eine Migration den Aufwand wert ist, oder ob die neue Funktion primär für neue Anwendungsfälle infrage kommt.

Workflow-Enrollments bleiben bei Merges erhalten

Wer mit HubSpot in größerem Maßstab arbeitet, kennt das Problem: Zwei Kontakte oder Deals werden zusammengeführt, und Automatisierungen, die auf einem der beiden Datensätze liefen, brechen ab oder starten neu. Das klingt nach einem Detail, hat aber operative Konsequenzen, etwa wenn ein Onboarding-Workflow für einen Neukunden mitten im Ablauf steht und der Kontakt aufgrund eines doppelten Imports gemergt wird.

Mit dem Update bleiben aktive Workflow-Enrollments beim Merge erhalten. Das klingt unspektakulär, ist aber ein gutes Beispiel dafür, wie Datenqualitätsarbeit und Automatisierung zusammenhängen. Deduplizierung ist in den meisten CRM-Systemen ein Dauerthema, gerade wenn mehrere Quellen (Formulare, Import, Sales-Eingabe, Integrationen) parallel Datensätze erzeugen. Bisher mussten Teams abwägen: Merge sofort durchführen und Automatisierungsrisiko in Kauf nehmen, oder Merge verzögern und mit doppelten Datensätzen leben. Diese Abwägung entfällt nun zumindest für den Automatisierungsteil.

App Objects in Association Workflow Actions

Die dritte Änderung betrifft ein technisches Detail mit größerer Tragweite: Workflow-Aktionen zur Verknüpfung von Objekten unterstützen jetzt auch App Objects, also benutzerdefinierte Objekte, die von Apps aus dem HubSpot-Marketplace bereitgestellt werden. Das ist relevant, weil viele Unternehmen inzwischen nicht nur mit den Standardobjekten (Kontakt, Unternehmen, Deal, Ticket) arbeiten, sondern mit Custom Objects für Abonnements, Standorte, Projekte oder Assets, die oft über installierte Apps ins System kommen.

Bisher war die Verknüpfung solcher App Objects in Workflows umständlich oder erforderte einen Umweg über die API. Die native Unterstützung reduziert Custom Code an einer Stelle, die in komplexeren CRM-Architekturen häufiger vorkommt, als man denkt: Verkauft ein Unternehmen beispielsweise Software-Lizenzen über eine Billing-App und will automatisiert Deal, Lizenz-Objekt und Kontakt verknüpfen, war das bisher ein Fall für eigene Middleware. Jetzt lässt sich das im Workflow-Builder abbilden.

Was das für Entscheider bedeutet

Alle drei Änderungen folgen demselben Muster: HubSpot verlagert Logik, die früher extern (per Middleware oder Custom Code) gelöst werden musste, in die Plattform selbst. Das ist grundsätzlich positiv, weil es Wartungsaufwand reduziert und die Fehleranfälligkeit sinkt, wenn ein System weniger externe Abhängigkeiten hat. Es hat aber auch eine Kehrseite, die in der Praxis oft übersehen wird.

• Native Funktionen sind an HubSpots Release-Zyklus gebunden. Wer heute eine Middleware-Lösung baut, kann sie unabhängig von HubSpot weiterentwickeln. Wer auf native Features setzt, ist von deren Weiterentwicklung und Limitierungen abhängig.
• Mit wachsender nativer Funktionsvielfalt wächst auch die Komplexität der Konfiguration. Webhook-Datenquellen, Merge-Verhalten und Association-Workflows sind einzeln einfach, in Kombination kann die Fehlersuche bei unerwartetem Verhalten aufwendiger werden.
• Architekturentscheidungen, die vor zwei oder drei Jahren getroffen wurden (etwa "wir bauen das über Zapier", weil HubSpot das nicht konnte), sollten regelmäßig überprüft werden. Was damals alternativlos war, ist es heute oft nicht mehr.

Handlungsempfehlungen für RevOps-Teams

Für Teams, die HubSpot als zentrales CRM-System betreiben, ergeben sich aus dem Rollup konkrete Prüfpunkte:

• Bestehende Middleware-Integrationen auflisten und prüfen, welche davon durch native Webhook-Datenquellen ersetzt werden könnten, insbesondere wenn die Integration primär Reporting-Daten liefert.
• Merge-Prozesse und Deduplizierungs-Workflows dokumentieren und testen, ob sich das Verhalten bei aktiven Automatisierungen wie erwartet ändert, bevor man sich darauf verlässt.
• Bei Custom Objects aus installierten Apps prüfen, ob bestehende Workaround-Lösungen für Verknüpfungen jetzt durch native Workflow-Aktionen ersetzt werden können.
• Grundsätzlich: Changelog-Updates nicht nur als Feature-Liste lesen, sondern regelmäßig gegen die eigene Architektur spiegeln. Viele Unternehmen zahlen weiterhin für Middleware-Lösungen, die HubSpot inzwischen nativ abdeckt.

Der August-Rollup ist kein Update mit spektakulären neuen Features, sondern eine Serie von Detailverbesserungen, die typische operative Reibungspunkte adressieren. Genau solche Updates lohnt es sich, systematisch zu verfolgen, weil sie über die Zeit den Unterschied zwischen einer gewachsenen, fragilen Integrationslandschaft und einer schlanken, wartbaren CRM-Architektur ausmachen.

Häufig gestellte Fragen

Ersetzen die neuen Webhook-Datenquellen bestehende Middleware-Tools wie Zapier oder Make komplett?

Nein, nicht generell. Sie decken den Fall ab, in dem externe Systeme Events per Webhook an HubSpot senden, um sie für Data-Studio-Reports nutzbar zu machen. Komplexere Transformationslogik, mehrstufige Automatisierungen oder Verbindungen zu Drittsystemen jenseits von HubSpot laufen weiterhin sinnvoller über dedizierte Middleware.

Was passiert konkret mit einem Workflow, wenn zwei Datensätze gemergt werden?

Nach dem Update bleibt die aktive Registrierung im Workflow für den überlebenden (primären) Datensatz erhalten, statt dass die Automatisierung durch den Merge unterbrochen oder neu gestartet wird. Das reduziert das Risiko, dass zeitkritische Prozesse wie Onboarding- oder Lead-Routing-Workflows durch Datenpflegemaßnahmen ausgebremst werden.

Was sind App Objects und warum ist die Unterstützung in Association-Workflows relevant?

App Objects sind benutzerdefinierte Objekte, die über eine im HubSpot-Marketplace installierte App bereitgestellt werden, etwa für Abonnements, Lizenzen oder Standorte. Bisher mussten Verknüpfungen dieser Objekte mit Standardobjekten oft über die API oder externe Automatisierung gelöst werden. Die native Unterstützung in Workflow-Aktionen reduziert diesen Custom-Code-Bedarf.

Lohnt es sich, jeden monatlichen HubSpot-Rollup im Detail zu verfolgen?

Für Teams mit gewachsener CRM-Architektur ja, zumindest in Form eines kurzen monatlichen Reviews. Viele Rollups enthalten einzelne Änderungen, die bestehende Workarounds überflüssig machen oder neue Risiken bei aktueller Konfiguration mit sich bringen. Ein systematischer Blick verhindert, dass Teams länger als nötig an veralteten Lösungen festhalten.