Zapier Alternative für Lead-Funnels: Warum native CRM-Integrationen die Middleware ersetzen sollten

Warum du eine Zapier Alternative suchst und warum die Top-10-Listen die falsche Frage beantworten

Die Top-10-Listen vergleichen Automatisierungs-Tools generisch, während die eigentliche Frage lautet, ob dein Lead-Datenfluss überhaupt Middleware braucht. Montagmorgen, der Head of Sales fragt, warum seit Donnerstag keine Demo-Anfragen mehr in HubSpot ankommen. Du öffnest Zapier und findest den Grund nach zehn Minuten. Jemand hat im Formular ein Feld umbenannt, und der Zap läuft seitdem auf Fehler. Die Fehlermails gingen an ein Postfach, das ein ehemaliger Kollege eingerichtet hat.

Kommt dir das bekannt vor? Dann sitzt du wahrscheinlich auf einem Account mit Dutzenden Zaps, die über Jahre ad hoc entstanden sind. Einige davon kennt niemand mehr genau. Und die Rechnung steigt. Prüfe, wie dein Zapier-Plan Ausführungen abrechnet: Was zählt als Task, und wie viele Tasks erzeugt ein einzelner Lead, der durch einen mehrstufigen Zap läuft?

Also suchst du nach einer Zapier Alternative und landest auf den bekannten Listen. Dort tauchen regelmäßig Make (früher Integromat) und n8n auf, ergänzt um weitere Workflow-Tools. Die Listen vergleichen Preise, die Anzahl der Integrationen und AI-Features und behandeln Automation generisch, vom Slack-Ping bis zur Buchhaltung.

Für deinen Lead-Funnel greift dieser Vergleich zu kurz. Die Kette Formular → Automatisierung → CRM hat ein strukturelles Problem, das nicht verschwindet, wenn du das mittlere Glied austauschst. Jede Middleware zwischen Lead-Quelle und CRM ist ein weiterer möglicher Ausfallpunkt für deine Daten. Sie verursacht laufende Kosten, je nach Abrechnungsmodell auch pro Ausführung. Außerdem liegt sie außerhalb der Hoheit deines Funnel-Teams.

Für einen großen Teil deiner Zaps ist die Antwort deshalb klar: Die CRM-Integration gehört direkt an die Lead-Quelle. Für den Rest, also echte Multi-System-Workflows, bleiben Tools wie Make oder n8n eine gute Wahl.

Anatomie des Zapier-Stacks im Lead-Funnel: wo Leads und Daten verloren gehen

Leads und Daten gehen an jeder Übergabe zwischen zwei Systemen verloren, und meistens bricht es leise. Zapier arbeitet nach dem Trigger-Aktion-Prinzip: Ein Ereignis in App A löst eine oder mehrere Aktionen in App B, C und D aus. Zapier und Make funktionieren hier im Kern gleich, auch wenn Make von Szenarien und Modulen spricht.

Im typischen Lead-Funnel sieht die Kette so aus:

Formular-Submit → Zap-Trigger (Webhook oder Polling) → Formatter / Filter → HubSpot: Kontakt anlegen oder aktualisieren → HubSpot: Deal anlegen → Newsletter-Tool: Kontakt zur Liste → Slack: Benachrichtigung an Sales

Die häufigste Bruchstelle ist das Feld-Mapping. Der Zap referenziert Formularfelder über Namen oder IDs. Wenn du ein Feld umbenennst, eine Frage hinzufügst oder eine Variante für einen A/B-Test baust, zeigt das Mapping ins Leere. Je nach Konfiguration läuft der Zap dann auf Fehler oder schreibt leere Werte ins CRM. Das ist schlimmer, weil es niemand bemerkt.

Die zweite Bruchstelle sind Hidden Fields und UTM-Parameter. Damit utm_source oder gclid im CRM ankommen, müssen sie im Formular erfasst, im Submit mitgeschickt, im Zap gemappt und in HubSpot als Property angelegt sein. Fehlt eines dieser vier Glieder, verlierst du die Attribution genau der Leads, für die du Budget ausgibst.

Die dritte Bruchstelle betrifft die Geschwindigkeit. Prüfe, ob dein Trigger per Webhook sofort feuert oder per Polling arbeitet, also die Quell-App in Abständen nach neuen Daten abfragt. Bei Polling entsteht zwischen Submit und Kontakt-Anlage eine Verzögerung, die du im Funnel selbst nicht siehst. Optimiert dein Sales-Team auf Speed-to-Lead, solltest du diese Lücke messen, statt sie anzunehmen.

Die vierte Bruchstelle ist die Kostenlogik. Hier eine Beispielrechnung mit erfundenen, rein illustrativen Zahlen:

Die Formel ist simpel: Tasks = Leads × abrechenbare Aktionen. Dein Task-Volumen steigt mit jedem Lead, und je nach Plan-Stufe steigen damit auch die Kosten. Welche Schritte in deinem Setup tatsächlich als Task zählen, siehst du in deinem eigenen Task-Verlauf. Prüfe das, bevor du hochrechnest.

Die fünfte Bruchstelle ist organisatorisch. Wer bekommt den Alert, wenn ein Zap ausfällt? Wer prüft den Task-Verlauf? In vielen Teams lautet die ehrliche Antwort: niemand regelmäßig.

Diese Checkfragen helfen dir, den eigenen Stack einzuschätzen:

• Wann hat zuletzt jemand ein Formular geändert, ohne die zugehörigen Zaps zu prüfen?

• Kommen UTM-Parameter für jede aktive Kampagne vollständig in HubSpot an?

• Arbeiten deine Trigger per Webhook oder per Polling?

• Wie viele Minuten vergehen zwischen Submit und Kontakt-Anlage im CRM?

• An welche Adresse gehen Fehlermeldungen, und liest dort jemand mit?

• Wie viele Tasks pro Monat entfallen auf reine Formular-zu-CRM-Übergaben?

Drei Architekturen im Vergleich: Middleware, Self-Hosted oder nativ an der Lead-Quelle

Für deinen Lead-Funnel reicht es, drei Architekturen zu unterscheiden: gehostete Middleware, Self-Hosted und nativ an der Lead-Quelle. Die Tool-Wahl ergibt sich danach fast von selbst.

Gehostete Middleware: zum Beispiel Make

Gehostete Middleware funktioniert wie Zapier, nur mit anderer Oberfläche und anderer Preislogik. Make (früher Integromat) bietet einen visuellen Canvas mit Routern, Fehlerbehandlung und detaillierten Ausführungslogs. Bei komplexen Verzweigungen liegt Make oft vorn. Dafür braucht es etwas mehr Einarbeitung. Abgerechnet wird nach Operations beziehungsweise Credits, also ebenfalls pro Ausführung.

Architektonisch ändert sich bei allen gehosteten Plattformen nichts: Formular → Middleware → CRM. Das Glied in der Mitte bleibt, es heißt nur anders.

Open-Source und Self-Hosted: n8n

Wer nach „Zapier Alternatives free“ oder Open-Source-Optionen sucht, stößt schnell auf n8n. n8n ist quelloffen und lässt sich selbst hosten, steht aber unter einer eigenen Lizenz (Sustainable Use License) statt einer klassischen Open-Source-Lizenz. Du kannst JavaScript in Workflows einsetzen und behältst die Kontrolle über Infrastruktur und Daten.

Kostenlos ist n8n als Zapier Alternative nur bei der Software selbst. Self-Hosting bedeutet: Server, Updates, Backups, Monitoring und Sicherheitspatches liegen bei dir. Fällt der Server um drei Uhr nachts aus, landen keine Leads im CRM, bis jemand aus deinem Team reagiert. Für Teams mit DevOps-Kapazität ist das ein fairer Tausch. Für ein Growth-Team ohne Engineering-Support verschiebt es das Problem nur.

Nativ an der Lead-Quelle

Die dritte Option entfernt das mittlere Glied: Formular oder mehrstufiger Flow → CRM.

Der Funnel-Builder schreibt Kontakte, Properties und gegebenenfalls Deals direkt per API ins CRM. Das Mapping pflegst du dort, wo du auch das Formular baust, und wenn sich eine Frage ändert, siehst du das zugehörige Mapping im selben Interface. Du musst also nicht in einem zweiten Tool nachsehen, ob der Workflow noch das richtige Feld befüllt.

Die Entscheidungsmatrix

Die Matrix zeigt keine Rangfolge. Sie zeigt, wann Middleware ihren Wert entfaltet: sobald mehr als zwei Systeme beteiligt sind, etwa wenn ein Lead parallel ins CRM, in einen Slack-Channel und in ein Data Warehouse soll. Für eine reine Übergabe vom Formular ins CRM bezahlst du dagegen für Flexibilität, die du nicht nutzt, und holst dir einen weiteren Ausfallpunkt in die Kette.

HubSpot-Integration ohne Zapier: HubSpot-Formular vs. mehrstufiger Flow

Für eine HubSpot-Integration ohne Zapier brauchst du einen Funnel-Builder, der mehrstufige, testbare Flows baut und Leads nativ in HubSpot schreibt. An dieser Stelle stehen Growth-Teams typischerweise vor einem Dilemma. Das HubSpot-Formular ist nativ und zuverlässig, aber für CRO-Arbeit begrenzt. Ein flexibleres Drittanbieter-Formular kann besser konvertieren, etwa durch schrittweise Abfrage mit Progressive Disclosure, hängt dafür aber oft an einem Zap.

Was das HubSpot-Formular gut kann

Das native HubSpot-Formular schreibt Kontakte ohne Umweg ins CRM. Es dedupliziert über die E-Mail-Adresse, verknüpft Submits mit dem HubSpot-Tracking-Cookie und ordnet die Quelle automatisch zu. Abhängige Felder und mehrseitige Formulare sind möglich, laut HubSpots Produktseite aber teils erst in höheren Tarifen.

Die Grenzen zeigen sich bei der Gestaltung und beim Testen. Kartenbasierte Flows mit tiefem Conditional Branching, individuelle Mobile-Layouts und saubere Varianten-Tests pro Schritt sind dort aufwendig oder gar nicht umsetzbar. Für ein Kontaktformular im Footer reicht das. Für den Hauptfunnel deiner Paid-Kampagnen reicht es meist nicht.

Was klassische statische Formular-Builder mitbringen

Klassische statische Formular-Builder bieten mehr Designfreiheit. Die Daten schicken sie aber oft nur per Webhook oder über eine flache Integration weiter. Für Lifecycle Stages, Deals oder Custom Properties landest du dann doch wieder bei Zapier, und damit kaufst du alle Bruchstellen aus dem vorigen Abschnitt mit ein.

Der dritte Weg: Funnel-Builder mit nativer HubSpot-Integration

Ein Funnel-Builder mit eigener HubSpot-Integration verbindet CRO-taugliche, mehrstufige Flows mit direkter Übergabe ins CRM. Ein Beispiel: Heyflow, die Funnel-Plattform für Paid Traffic, schreibt Leads in allen Plänen nativ in HubSpot, Pipedrive, Zoho CRM, HighLevel und ActiveCampaign, ab dem Scale-Plan auch in Salesforce, und für Recruiting in Personio, Recruitee und softgarden. Für alle anderen Ziele gibt es Make in allen Plänen und Webhooks ab dem Growth-Plan. Das Mapping pflegst du im selben Editor, in dem du den Funnel baust. Unabhängig vom Tool gilt: Welche Objekte, Sync-Richtungen und Property-Typen eine Integration konkret unterstützt, prüfst du vor der Migration in der aktuellen Dokumentation.

Egal welches Tool du nutzt: Diese Mapping-Checkliste entscheidet, ob die HubSpot-Integration im Alltag trägt.

• Kontakt-Properties: Jedes Formularfeld braucht eine passende HubSpot-Property mit dem richtigen Feldtyp. Dropdown-Werte im Formular müssen exakt den internen Werten der Property entsprechen, sonst lehnt die API den Wert ab oder lässt ihn leer.

• Lifecycle Stage: Formulare, Importe und API-Integrationen können die Lifecycle Stage in HubSpot nur vorwärts setzen; zurück geht es erst, wenn der bestehende Wert geleert wurde. Lege fest, welche Stage ein Formular-Lead bekommt (Subscriber, Lead, MQL), und prüfe, was mit bestehenden Kontakten in späteren Stages passiert.

• Lead-Source und UTM: HubSpots automatische Quellzuordnung ist nützlich, aber nicht granular genug für Kampagnen-Reporting. Lege eigene Properties für utm_source, utm_medium, utm_campaign und Click-IDs an und befülle sie über Hidden Fields.

• Consent-Felder: Mappe Einwilligungen auf HubSpots Abo-Typen und die Rechtsgrundlage der Verarbeitung. Ein angehaktes Kästchen im Formular, das im CRM nirgends landet, ist für dein E-Mail-Marketing wertlos.

• Deal-Anlage: Wenn das Formular einen Deal erzeugen soll, definiere Pipeline, Stage, Owner und die Verknüpfung zu Kontakt und Unternehmen. Kläre, ob bei wiederholten Anfragen ein neuer Deal entsteht oder der bestehende aktualisiert wird.

• Duplikat-Logik: HubSpot erkennt Kontakte über die E-Mail-Adresse. Wenn dein Formular optional ohne E-Mail abschickt, etwa nur mit Telefonnummer, entstehen Dubletten. Mach die E-Mail zum Pflichtfeld oder plane eine Bereinigung.

Arbeite diese sechs Punkte vor dem Go-live einmal mit einem Test-Lead durch. Das dauert eine Stunde und erspart dir Wochen mit unvollständigen Datensätzen.

Datenqualität entsteht im Funnel

Datenqualität entsteht bei der Eingabe, nicht in der Middleware: Viele Zaps reparieren nur, was das Formular hätte verhindern können. Öffne einen beliebigen Lead-Zap und zähle die Schritte zwischen Trigger und CRM-Aktion. Oft findest du einen Formatter, der Telefonnummern normalisiert, daneben einen Filter, der Testeinträge aussortiert, und einen Paths-Schritt, der Leads nach Unternehmensgröße routet.

Das ist der unterschätzte Teil der Middleware-Debatte. Viele Zaps sind keine Automatisierung im eigentlichen Sinn, sondern Reparaturwerkstätten für schlecht strukturierte Eingaben.

Ein mehrstufiger Flow verlagert diese Arbeit an den Anfang. Die Telefonnummer wird bei der Eingabe validiert und im richtigen Format gespeichert. In Heyflow wird die Nummer dabei auf Carrier-Ebene geprüft (ab dem Growth-Plan), und E-Mail-Adressen werden vor dem Absenden validiert. Die Unternehmensgröße fragst du als Auswahl mit festen Werten ab, die exakt deiner HubSpot-Property entsprechen. Freitext, den später jemand interpretieren muss, entfällt.

Conditional Branching erledigt das Routing, das sonst im Zap passiert. Wählt jemand „1 bis 10 Mitarbeitende“, bekommt er andere Folgefragen als ein Lead aus einem Konzern. Irrelevante Fragen tauchen gar nicht erst auf. Im CRM kommt ein Datensatz an, der schon qualifiziert und segmentiert ist, und deine Lead-Qualifizierungsgeschwindigkeit steigt, weil Sales nicht mehr nachfragen muss.

Das Prinzip dahinter heißt Progressive Disclosure: ein bis zwei Fragen pro Schritt, die nächste erst nach der Antwort. Die frühen, leichten Fragen wirken als Micro-Commitments. Wer drei Karten geklickt hat, bricht seltener ab, wenn die vierte nach der E-Mail-Adresse fragt. Die Antworten sind Zero-Party-Daten, also Informationen, die der Lead dir bewusst gibt, und keine Schätzung aus Enrichment-Tools.

Auf dem Smartphone wirkt das besonders stark. Große Antwortkarten mit ausreichend Touch-Fläche und automatischem Weiterspringen bei Einfachauswahl sind dort deutlich angenehmer als ein langes Formular mit kleinen Eingabefeldern. Wie hoch der mobile Anteil deines Funnel-Traffics ist, zeigen dir deine Analytics; bei Paid Social ist er meist hoch.

Der naheliegende Einwand: Mehr Schritte bedeuten mehr Abbrüche. Das stimmt nur, wenn jeder Schritt Aufwand erzeugt. Abbrüche entstehen durch wahrgenommene kognitive Last, und ein statisches Formular mit zwölf sichtbaren Feldern signalisiert schon beim ersten Blick hohen Aufwand. Eine einzelne Frage mit drei Antwortkarten signalisiert das Gegenteil, auch wenn am Ende mehr Fragen beantwortet werden.

Das kannst du testen, statt es zu glauben. Bau den bestehenden Single-Page-Funnel als mehrstufigen Flow nach und teste beide Varianten gegeneinander. Miss die Completion Rate, aber auch den Anteil vollständiger, verwertbarer Datensätze im CRM. Die zweite Metrik ist die, die Sales interessiert.

DSGVO und Datenfluss: jedes zusätzliche Tool ist ein weiterer Auftragsverarbeiter

Jede Middleware im Lead-Fluss verarbeitet personenbezogene Daten und ist damit Auftragsverarbeiter nach Art. 28 DSGVO, mit eigenem Vertrag, Verzeichniseintrag und gegebenenfalls Drittlandtransfer. Oft kommt die Suche nach einer Zapier Alternative genau von dieser Frage aus der Rechtsabteilung: Wo liegen die Lead-Daten, wenn sie durch Zapier laufen, und wie lange?

Die Middleware verarbeitet Namen, E-Mail-Adressen, Telefonnummern, teilweise Angaben zu Budget oder Gesundheitsthemen. Du brauchst einen Auftragsverarbeitungsvertrag, einen Eintrag im Verzeichnis der Verarbeitungstätigkeiten und bei Anbietern außerhalb der EU eine Grundlage für den Drittlandtransfer.

Für US-Anbieter ist das seit Juli 2023 häufig das EU-U.S. Data Privacy Framework, sofern der Anbieter zertifiziert ist. Prüf das für jeden Anbieter einzeln. Viele Middleware-Tools speichern Ausführungsdaten im Task-Verlauf oder in Logs, oft für einen definierten Zeitraum. Diese Kopien deiner Leads liegen dann außerhalb deines CRM.

Für jedes Tool in der Kette solltest du diese Punkte verifizieren:

• Liegt ein unterschriebener Auftragsverarbeitungsvertrag vor?

• In welcher Region werden Daten gespeichert und verarbeitet, und ist EU-Datenresidenz vertraglich zugesichert oder nur verfügbar?

• Welche Subprozessoren setzt der Anbieter ein?

• Wie lange werden Ausführungsdaten und Logs aufbewahrt, und kannst du die Frist verkürzen?

Self-Hosting mit n8n löst einen Teil davon, weil du den Serverstandort selbst bestimmst. Dafür trägst du die volle Verantwortung für Zugriffsschutz, Verschlüsselung und Patches.

Eine native Integration reduziert die Zahl der Auftragsverarbeiter um einen. Sie macht die Prüfung nicht überflüssig: Formular-Anbieter und CRM musst du genauso auf Hosting-Region, Vertrag und Subprozessoren prüfen. Die Kette wird kürzer, die Pflicht bleibt.

Der Zap-Audit: Brücken von Workflows trennen

Statt Zapier komplett gegen Make oder n8n zu tauschen, sortierst du jeden Zap in eine von zwei Gruppen: Formular-zu-CRM-Brücken, die du nativ verlagerst, und Multi-System-Workflows, die in der Middleware bleiben. Der Einwand gegen den Ansatz ist berechtigt: Dein Setup läuft, du hast zu viele Zaps für einen Komplettumbau, und native Integrationen sind oft flacher als ein individuell gebauter Zap. Ein Middleware-Tausch verschiebt das Kernproblem aber nur, und du baust dabei auch die Zaps neu, die gar keine Middleware brauchen.

Exportiere die Liste deiner Zaps und ordne jeden einzelnen zu:

Für die Einordnung jedes Zaps helfen dir diese Prüfschritte:

1. Notiere Trigger-App und alle Aktions-Apps. Sind es nur Formular und CRM, ist der Zap ein Kandidat für die Migration.

2. Markiere Formatter-, Filter- und Paths-Schritte. Prüfe für jeden, ob Validierung oder Conditional Logic im Formular denselben Zweck erfüllt.

3. Ermittle die Tasks pro Monat aus dem Verlauf. Die Brücken mit dem höchsten Volumen migrierst du zuerst.

4. Prüfe, ob der Zap Daten an Systeme weitergibt, die der Funnel selbst bedienen kann. Slack-Benachrichtigungen an Sales schickt Heyflow nativ, Slack ist in allen Plänen enthalten. Diesen Zap kannst du also abschalten.

5. Dokumentiere Owner und Fehler-Empfänger für jeden Zap, der bleibt.

Danach migrierst du Brücke für Brücke. Bau das Formular als Flow mit nativer CRM-Integration neu, setze die Mapping-Checkliste aus dem HubSpot-Abschnitt um und lass alten und neuen Weg ein paar Tage parallel laufen. Vergleiche die Datensätze im CRM, bevor du den Zap abschaltest.

Was übrig bleibt, sind die Workflows, für die Middleware gebaut wurde. Für diese kannst du immer noch entscheiden, ob Zapier, Make oder n8n am besten passt. Die Entscheidung ist dann kleiner und besser begründet, weil sie nur noch echte Multi-System-Logik betrifft.

Wo native Integrationen an ihre Grenzen stoßen

Native Integrationen stoßen an Grenzen, sobald ein Lead in mehrere Systeme gleichzeitig muss, vorab angereichert werden soll oder über viele Teams geroutet wird. Sie decken in der Regel die Übergabe von der Lead-Quelle an ein CRM ab. Muss ein Lead parallel ins CRM, in ein Data Warehouse und in ein Terminbuchungstool, brauchst du mehr.

Enrichment ist der zweite Grenzfall. Wenn du jeden neuen Lead mit Firmografie-Daten aus einem externen Dienst anreicherst, bevor er ins CRM geht, brauchst du einen Zwischenschritt. Das kann ein Webhook an n8n oder Make sein. Alternativ läuft das Enrichment erst im CRM.

Komplexes Lead-Routing über mehrere Teams, Länder und Produktlinien gehört ebenfalls oft in Middleware oder direkt ins CRM. Die Verzweigung im Formular übernimmt die Qualifizierung, die Zuweisung an einzelne Reps erledigen HubSpot-Workflows oder Salesforce-Assignment-Rules besser.

Und ja, du bindest dich stärker an dein Funnel-Tool, weil das Mapping dort liegt. Das ist ein echter Trade-off. Er wiegt weniger schwer, als er klingt, denn auch ein Zap ist an die Feldstruktur deines aktuellen Formular-Tools gebunden und muss bei einem Wechsel neu gebaut werden.

Die saubere Architektur kombiniert deshalb beides: native CRM-Integration für die Brücken, Webhooks aus dem Funnel-Builder für Sonderfälle und Middleware nur für echte Multi-System-Workflows. Das ist die Zapier Alternative, die für Lead-Funnels tatsächlich trägt.

Dein nächster Schritt: der Zap-Audit in 60 Minuten

Blocke dir diese Woche eine Stunde und exportiere deine Zap-Liste. Markiere jeden Zap, der nur Formular und CRM verbindet, und trag daneben die Tasks des letzten Monats ein. Allein diese Spalte zeigt dir, wie viel deiner Middleware-Rechnung auf reine Übergaben entfällt.

Nimm dir dann die Brücke mit dem höchsten Volumen vor, idealerweise deinen wichtigsten Paid-Funnel. Bau ihn als mehrstufigen Flow mit nativer HubSpot-Integration nach, arbeite die Mapping-Checkliste ab und prüf für jedes beteiligte Tool Auftragsverarbeitungsvertrag und Datenresidenz. Lass beide Varianten parallel laufen und vergleiche die Conversion Rate und die Vollständigkeit der Datensätze in HubSpot.

Wenn die neue Variante sauberere Daten liefert und kein Lead verloren geht, schaltest du den Zap ab. Dann folgt die nächste Brücke. Nach drei oder vier Durchläufen ist dein Zapier-Account deutlich kleiner, und was dort bleibt, hat einen klaren Zweck und einen Owner, der den Alert auch liest.

Häufige Fragen

Was ist die beste Zapier Alternative für Lead-Funnels?

Für reine Übergaben vom Formular ins CRM ist eine native CRM-Integration im Funnel-Builder die robusteste Lösung, weil sie das mittlere Glied entfernt. Für Workflows mit drei oder mehr Systemen bleiben Make oder n8n gute Alternativen zu Zapier.

Ist n8n eine kostenlose Zapier Alternative?

Die selbst gehostete Community Edition ist quelloffen und für interne Zwecke kostenlos. Beim Self-Hosting trägst du aber Server, Updates, Backups, Monitoring und Sicherheitspatches selbst, und diese Arbeitszeit kostet.

Welche CRM-Integrationen hat Heyflow nativ?

In allen Plänen schreibt Heyflow Leads nativ in HubSpot, Pipedrive, Zoho CRM, HighLevel und ActiveCampaign, im Recruiting in Personio, Recruitee und softgarden. Salesforce ist ab dem Scale-Plan enthalten. Für andere Systeme gibt es Make in allen Plänen und Webhooks ab dem Growth-Plan.

Kann ein Formular die Lifecycle Stage in HubSpot zurücksetzen?

Nein. Formulare, Importe und API-Integrationen setzen die Lifecycle Stage nur vorwärts. Für einen früheren Wert musst du die Property zuerst manuell oder per Workflow leeren.

Ist Zapier DSGVO-konform nutzbar?

Ja, wenn ein Auftragsverarbeitungsvertrag vorliegt, die Verarbeitung im Verzeichnis dokumentiert ist und für den Drittlandtransfer eine Grundlage besteht, etwa das EU-U.S. Data Privacy Framework. Prüf außerdem, wie lange Ausführungsdaten in den Logs bleiben.

Weiterführende Artikel

• DSGVO-konformer Funnel-Builder

• Heyflow Preise

• Heyflow: die Funnel-Plattform für Paid Traffic