--- title: "Wie fügen Sie Ihrer Website ein Kontaktformular hinzu, das direkt in Ihr CRM schreibt?" blueprint: 013 slug: website-contact-form-into-crm category: Lead-Erfassung published: 2026-09-23 revised: 2026-09-23 platform: Coevera CRM (formerly Pipeliner CRM) canonical: https://blueprints.coevera.com/de/blueprints/website-contact-form-into-crm/ language: de translation_of: https://blueprints.coevera.com/blueprints/website-contact-form-into-crm/ author: Lucia Schmidt publisher: Coevera customer_data: none --- # Wie fügen Sie Ihrer Website ein Kontaktformular hinzu, das direkt in Ihr CRM schreibt? **Kurze Antwort.** **Ein Kontaktformular ist ein Onlineformular, das das CRM hostet und die Website einbettet.** Jede Formulardefinition trägt eine `linkId`, und das öffentliche Formular liegt unter einer URL, die aus dieser ID gebildet wird. Die Seite hält diese URL und einen barrierefreien Titel – **kein Formular-Markup, keine Feldliste, keinen Endpunkt, keinen API-Schlüssel**. Die Fragen ändern sich also im CRM, ohne Website-Deployment. Machen Sie die Übermittlung dann zu einem **Upsert**: Aktivieren Sie `createRecordEnabled`, `updateRecordEnabled` *und* `autolinkEnabled` gemeinsam. Autolink gleicht die übermittelte E-Mail-Adresse mit dem E-Mail-Feld des Kontakts ab, sodass ein wiederkehrender Bewerber seinen eigenen Datensatz aktualisiert, statt zu einem zweiten zu werden. Bei einem Live-Formular: **49 Übermittlungen, 41 Personen, nichts nicht zugeordnet.** Der Haken ist die Messung. Ein eingebettetes Formular hat keine Empfänger, also hat es **keine Rücklaufquote und keine Nachfassliste** – beides muss als Reporting über die Datensätze nachgebaut werden, die es angelegt hat. ## 01 · Das Geschäftsproblem Jede Website hat eines: das Formular hinter *Kontakt*, *Jetzt bewerben*, *Rückruf anfordern*, *Hier registrieren*. Es ist jedes Mal dieselbe Anforderung, was auch immer auf dem Button steht – ein Fremder tippt seine Daten auf einer öffentlichen Seite ein, und die Übermittlung muss sofort zu einem echten Datensatz werden. Nicht zu einer Benachrichtigung, die jemand ins CRM abtippt, und nicht zu einer Tabellenzeile. In der Praxis heißt das all dies zugleich: - Die Person wird zu einem Datensatz, der einen **Eigentümer** hat, **typisiert** ist und mit ihrer Herkunft gestempelt wird; - wer zweimal übermittelt, wird **nicht** zu zwei Personen; - der Bewerber erhält sofort eine Bestätigung; - die richtige interne Person wird informiert; - bei den Personen, die begonnen und nie abgeschlossen haben, wird nachgefasst; - und das Marketing kann die Seite umgestalten und ein Administrator eine Frage hinzufügen, **ohne dass einer auf den anderen warten muss**. Diese letzte Bedingung ist es, an der die meisten Umsetzungen scheitern. Ein Formular, dessen Feldliste im Code der Website lebt, macht jede Frage zu einem Deployment, sodass der Fragensatz auf dem Stand vom Starttag einfriert. ## 02 · Warum der naheliegende Ansatz scheitert ### Das Formular im eigenen Stack der Website bauen Der Reflex ist, das Formular von Hand in dem Framework zu bauen, das die Website nutzt, und es per POST an die API des CRM zu schicken. Das funktioniert am ersten Tag und verfällt von da an. Die Feldliste existiert nun an zwei Orten und muss von Hand synchron gehalten werden; eine Frage hinzuzufügen ist eine Codeänderung, ein Review und ein Release; und die Website ist nun verantwortlich für Validierung, für Spam und für das Aufbewahren von Zugangsdaten, die ins CRM schreiben können. Jedes dieser Probleme hat das gehostete Formular bereits gelöst. ### Ein Formularprodukt plus eine Automatisierungsbrücke Ein Formularwerkzeug eines Drittanbieters, angebunden über eine Integrationsplattform, fügt einen Zwischenschritt hinzu, der still scheitern kann, und es liefert einen Datensatz ohne Untertyp, ohne Eigentümer und ohne Herkunft, weil die Brücke Ihr Datenmodell nicht kennt. Dann brauchen Sie einen Abgleichprozess, um die Arbeit zu beenden, die das Formular hätte erledigen sollen. ### Das Markup des Formulars in die Seite kopieren Es gibt kein Markup zum Kopieren. Das gehostete Formular ist eine JavaScript-Anwendung, die von einem statischen CDN ausgeliefert und zur Laufzeit über ihre Link-ID aufgelöst wird; das HTML unter dieser URL ist eine Hülle von etwa 1,7 KB mit einem einzigen benutzerdefinierten Element. Was auch immer die Felder des Formulars auslesen oder neu hosten will, findet dort nichts. ### Pro Übermittlung einen Datensatz anlegen Der teuerste Fehler ist der einfachste: das Anlegen von Datensätzen einzuschalten und sonst nichts. Menschen senden öffentliche Formulare ganz selbstverständlich erneut ab – sie verlieren die Bestätigung, sind unsicher, ob es geklappt hat, ändern eine Antwort. Bei einem Live-Bewerbungsformular kamen **49 Übermittlungen von 41 Personen**. Nur-Anlegen hätte bei einem so kleinen Formular acht doppelte Kontakte erzeugt, jeder mit seiner eigenen nachgelagerten E-Mail, und die Rechnung für die Deduplizierung kommt später mit Zinsen. ### Annehmen, der Bewerber sei ein Lead Öffentliches Formular, unbekannte Person – also sicher ein Lead. Nicht unbedingt. Wer einem Programm beitritt, geht eine Beziehung ein, nicht in eine Vertriebspipeline: Er hat keinen Deal, keinen Wert und kein Abschlussdatum, und ihn in eine Pipeline zu stellen, macht jede Pipeline-Kennzahl falsch. Binden Sie das Formular an die Entität, die dem entspricht, was die Person tatsächlich ist. Die Platzierungsfrage behandelt [Blueprint 003](https://blueprints.coevera.com/de/blueprints/where-should-this-data-live/). ## 03 · Datenmodell Die drei beteiligten Entitäten – die Formulardefinition, die Antwort und die Verknüpfung – werden in [Blueprint 012](https://blueprints.coevera.com/de/blueprints/customer-survey-answers-onto-the-record/) behandelt. Spezifisch ist hier die Grenze zwischen Website und CRM. **Quellen.** Coevera-Hilfecenter, [Working with online forms](https://help.coevera.com/en/articles/8039971-working-with-online-forms) für das Formular selbst und für die hier genutzte iframe-Einbettung, die der Artikel die einfachste Option nennt, jedoch mit Einschränkungen; und [Working with online forms in JavaScript](https://help.coevera.com/en/articles/8287702-working-with-online-forms-in-javascript-developers-tutorial) für den anderen Weg, ein per Skript eingebettetes Formular, das Teil der Seite ist. ### Die Kopplung ist ein einziger undurchsichtiger String Eine Formulardefinition stellt `linkId` bereit, und das öffentliche Formular wird unter einer URL dieser Form ausgeliefert: ``` https://forms.{vendor-host}/{link-id}/viewform ``` Die Website speichert diese URL und einen lesbaren Titel, sonst nichts. In einer Live-Umsetzung hält das eigene Inhaltsmodell der Seite genau zwei Schlüssel für das Formular – die URL und den Titel –, und der Button öffnet es beim Klick in einem modalen Frame. Der Titel ist keine Dekoration: Er wird zum barrierefreien Namen des Frames, und das ist das Einzige, was ein Screenreader ansagen kann, bevor der Inhalt des Frames lädt. > **Warum genau darum alles geht.** Weil die Website keine Feldnamen hält, ist das Hinzufügen, > Entfernen oder Umordnen einer Frage eine Änderung im CRM ohne Website-Release. Und weil sie > keine Zugangsdaten hält, kann niemand, der ihren Quelltext liest, die Seite in einen Schreibweg > gegen Ihr CRM verwandeln. ### Was das Einbetten tatsächlich kostet Die Antwort des gehosteten Formulars trägt weder `X-Frame-Options` noch eine Einschränkung per `frame-ancestors`, und genau deshalb lässt es sich überall einbetten. Als iframe eingebettet, wie hier, ergeben sich drei Folgen, und alle drei werden meist spät entdeckt: - **Es ist nicht crawlbar.** Im iframe werden die Fragen per Skript gerendert, sodass Suchmaschinen und Modelle nur die Hülle sehen. Jeder Inhalt, der indexiert werden soll, muss auf der Seite um den Frame herum stehen, nicht darin. - **Ohne JavaScript gibt es kein Formular.** Kein eingeschränktes Formular – nichts. - **Die übergeordnete Seite kann nicht in den Frame hineinsehen.** Steht das Formular in einem iframe, sehen Ihre Analyse- und Einwilligungswerkzeuge den Klick, der ihn geöffnet hat, und nichts danach, sodass Abbrüche auf Feldebene von außen unsichtbar sind. Und da nichts einschränkt, wer das Formular einrahmen darf, lässt es sich auch auf einer Website einbetten, die nicht Ihnen gehört. Die Link-ID ist das einzige Geheimnis, und sie steht in Ihrem Seitenquelltext. ### Formularfelder werden zwischen Formularen geteilt Formularfelddefinitionen liegen in einem Pool für den ganzen Space statt in einem einzelnen Formular. Vier Feldkennungen in diesem Bewerbungsformular – Vorname, Nachname, E-Mail, Firma – sind identisch mit denen einer davon unabhängigen Kundenumfrage im selben Space. „Eine E-Mail-Frage hinzufügen“ verwendet also eine bestehende Definition wieder, statt eine neue anzulegen. Ob sich die Bearbeitung einer geteilten Definition auf jedes Formular auswirkt, das sie nutzt, wurde nicht getestet; prüfen Sie das, bevor Sie eine umbenennen. ### Was der Datensatz braucht und der Besucher nicht liefern kann Ein angelegter Datensatz muss trotzdem die gewöhnlichen Anforderungen der Plattform erfüllen, und eine anonyme Übermittlung erfüllt keine davon: | Erforderlich | Woher es kommt | |---|---| | Eigentümer | Eine feste ID in der Anlagevorlage. Es gibt niemanden, aus dem er sich ableiten ließe | | Vertriebseinheit | Ebenfalls fest. Ein Datensatz mit Eigentümer und ohne Einheit wird voraussichtlich abgelehnt; keine Übermittlung hat das getestet | | Untertyp | Eine feste Typ-ID, damit Bewerber auf Datensatzebene von allen anderen auf derselben Entität unterscheidbar sind – das Muster mit dem Unterscheidungsmerkmal aus [Blueprint 001](https://blueprints.coevera.com/de/blueprints/one-entity-five-request-types/) | | Herkunft | Von der Vorlage gestempelt – siehe §4 | ## 04 · Konfiguration auf Feldebene ### Der Fragensatz, und was „Pflicht“ bedeuten sollte Das Live-Formular stellt elf Fragen, neun davon verpflichtend: | Frage | Formularfeldtyp | Pflicht | |---|---|---| | First name, Last name | einzeilige Eingabe | ja | | E-mail | E-Mail | ja – und sie ist der Autolink-Schlüssel | | Phone | einzeilige Eingabe | ja | | Company name | einzeilige Eingabe | **nein** | | Street | **Textbereich** | ja | | City, Zip, Country | einzeilige Eingabe | ja | | State | einzeilige Eingabe | nein | | Privacy & data protection | Checkbox | ja | Zwei Dinge aus dieser Tabelle sind es wert, übernommen zu werden. Erstens: **Der Formularfeldtyp folgt dem Typ des CRM-Felds, nicht der Frage** – die Frage nach der Straße ist ein Textbereich, weil das zugrunde liegende Adressfeld des Kontakts mehrzeilig ist, und keine Konfiguration am Formular ändert das. Zweitens: Die Pflichtfelder sind nicht die Wunschliste des Marketings – eine vollständige Postanschrift ist verpflichtend, weil das Programm Menschen bezahlt und ohne sie nicht weiterkommt, während der Firmenname – das Feld, auf dem ein Marketer bestehen würde – optional ist. **Verlangen Sie das, ohne das der nächste Schritt tatsächlich nicht laufen kann**, und sonst nichts. Beachten Sie auch, dass bei jedem Feld die Vorbefüllung ausgeschaltet ist. Es gibt keinen Datensatz, aus dem vorbefüllt werden könnte; die Kombination aus Vorbefüllung und Autolink, die in [Blueprint 012](https://blueprints.coevera.com/de/blueprints/customer-survey-answers-onto-the-record/) einen bekannten Kunden identifiziert, greift nicht, wenn der Antwortende ein Fremder ist. ### Die drei Einstellungen, die es zu einem Upsert machen | Einstellung | Wert | Wirkung | |---|---|---| | `createRecordEnabled` | `true` | Eine nicht zugeordnete Übermittlung wird zu einem neuen Datensatz | | `updateRecordEnabled` | `true` | Eine zugeordnete Übermittlung aktualisiert den bestehenden | | `autolinkEnabled` | `true` | Entscheidet, welches von beiden passiert | | `autolinkFormFieldId` / `autolinkRecordFieldId` | die E-Mail-Frage / das E-Mail-Feld des Kontakts | Der Abgleich. Das sind zwei getrennte Kennungen in zwei verschiedenen ID-Räumen – sie zu paaren ist die ganze Konfiguration | | `linkRecordEnabled` | `false` | Nichts, womit verknüpft werden könnte; die Identität wird durch die Antwort festgestellt, nicht durch einen Versand | | `limitToSingleResponse` / `checkForExistingResponse` | `false` | **Hier richtig.** Wiederholte Übermittlungen sind der Mechanismus, nicht das Problem | ### Die Anlagevorlage Mit `createRecordEnabled` trägt das Formular eine Datensatzvorlage. Sie ist eine **vollständige Datensatz-Nutzlast, kein Patch** – sie zählt die Standardfelder auf, einschließlich aller fünf Telefonplätze und aller fünf E-Mail-Plätze, die meisten davon leer: ``` { "contactTypeId": "{sub-type-id}", "ownerId": "{nominated-owner-id}", "unitId": "{nominated-unit-id}", "firstName": "", "lastName": "", "email1": "", "phone1": "", "address": "", "city": "…", "zipCode": "…", "stateProvince": "…", "country": "…", "email2": "", "email3": "", "phone2": "", "phone3": "", "middleName": "", "title": "", "position": "", "accountRelations": [], "tags": [], "staticProfiles": [], "shareMode": "Standard", "isUnsubscribed": false, "comments": "Created via {a hand-typed page path}", "customFields": { "cfRegistrationDate": "", "cfSource": "{the page URL}" } } ``` Die fünf Entscheidungen in dieser Nutzlast: - **Der Untertyp wird bei der Anlage gesetzt.** Das macht „alle, die sich über die Website beworben haben“ zu einer filterbaren Menge statt zu einer Vermutung. - **Eigentümer und Einheit werden festgelegt, nicht abgeleitet.** Beide sind Pflicht, und keines von beiden kann vom Besucher kommen. Wählen Sie einen bewussten Platzhalter statt des Kontos einer echten Person, sonst wird der Platzhalter versehentlich zur Arbeitslast von jemandem. - **Die Herkunft wird zweimal gestempelt** – einmal im Kommentartext und einmal in einem eigenen Quellfeld. Bevorzugen Sie das Feld: Es ist filterbar, auswertbar, und es veraltet nicht. Womit wir beim nächsten Punkt sind. - **Von Hand getippte Herkunft driftet.** In der Live-Vorlage widersprechen sich der Kommentar-String und das Quellfeld beim Seitenpfad, weil einer von beiden getippt und nie wieder angesehen wurde. Nichts prüft einen Freitext-String gegen die Wirklichkeit. Halten Sie eine einzige Quelle der Wahrheit und machen Sie sie zu einem Feld. - **Das Registrierungsdatum kommt aus `CurrentDate`**, nicht aus einem später laufenden Prozess. > **Das Einwilligungshäkchen steht nicht auf dem Datensatz.** Die Datenschutz-Checkbox ist für die > Übermittlung Pflicht – und taucht nirgends in der Anlagevorlage auf. Die Einwilligung existiert > also auf dem Antwortdatensatz und im Antwort-PDF und ist **auf dem Kontakt nicht abfragbar**. > Wenn Sie Einwilligungen je massenhaft filtern, auswerten oder nachweisen müssen, ordnen Sie sie > ausdrücklich einem eigenen Feld zu. Nichts warnt Sie, dass eine Pflichtfrage ins Leere ging. ### Die Benachrichtigung, und die eine Einstellung, die oft verkehrt herum gesetzt wird Setzen Sie `notificationEnabled` und richten Sie sie an **den Eigentümer des Formulars**, nicht an den Eigentümer des primären Datensatzes. Bei einem Erfassungsformular ist der Eigentümer des angelegten Datensatzes der festgelegte Platzhalter aus der Vorlage, sodass eine Benachrichtigung an den Datensatzeigentümer an einen Platzhalter geht. Das ist das Gegenteil der richtigen Antwort bei einer Umfrage an einen bestehenden Kunden, wo der Datensatzeigentümer die Person ist, die Bescheid wissen muss. ### Der Rest, kurz - **reCAPTCHA ist ein Flag pro Formular.** Es ist bei diesem Formular aus und beim allgemeinen Kontaktformular im selben Space an. Ein öffentliches Formular ohne reCAPTCHA sammelt Müll, und Müll in einem Upsert-Formular sind Müll-Datensätze. - **`attachResponseAsPdf`** legt die Übermittlung am Datensatz ab. Bei allem, was einer Bewerbung oder einer Vereinbarung ähnelt, macht das den Datensatz auch ein Jahr später noch belastbar. - **Die Bestätigungsseite ist ein Versprechen.** Steht dort „Anweisungen finden Sie in Ihrer E-Mail“, entsteht eine Verpflichtung, die §5 einlösen muss. ## 05 · Automatisierung & Logik ### Der Übermittlungs-Handler Ein Prozess, per ID an genau dieses Formular gebunden, der bei der Übermittlung auslöst. Seine Trigger-Entität ist die **Antwort**, und sein Datensatztyp ist der Kontakt, dem die Antwort zugeordnet wurde, sodass der Prozess im selben Lauf die Antworten lesen und auf die Person einwirken kann. In der Live-Umsetzung ist er bewusst klein – ein Filter, eine E-Mail – und existiert, um den Satz auf der Bestätigungsseite einzulösen. **Beobachtete Latenz:** Der Prozess lief zuletzt etwa **acht Sekunden** nach der letzten erfassten Antwort des Formulars. Das ist eine Beobachtung, kein Benchmark, aber sie klärt die Designfrage: Das ist eine Live-Übergabe, kein Batch, sodass die Bestätigungs-E-Mail Teil des Übermittlungserlebnisses sein kann. ### Die Kennzahl mit einem zweiten, versendeten Formular zurückholen Das Muster, das es wert ist, übernommen zu werden, ist das, was danach passiert. Das Bewerbungsformular ist eingebettet und kann daher nie eine Quote melden. Das anschließende *Vereinbarungsformular* wird **versendet** – und ein versendetes Formular meldet alles. Der Live-Funnel, von Anfang bis Ende: | Stufe | Gemessen | Was die Plattform meldet | |---|---|---| | Eingebettetes Bewerbungsformular | 49 Übermittlungen → **41 verschiedene Personen**, 0 nicht zugeordnet | Rücklaufquote: **leer**. Sendungszahl null | | Versendetes Vereinbarungsformular | 144 Sendungen an diese 41 Personen → **35 unterschrieben** | Rücklaufquote: **85,4 %**, dazu eine Liste der Nicht-Antwortenden | Aus dieser Tabelle ergeben sich zwei Lesarten. Die offensichtliche: **Legen Sie die messbare Stufe dorthin, wo die Entscheidung fällt**. Die subtilere: `sentCount ÷ sentUniqueCount` ist 144 ÷ 41 ≈ 3,5, sodass das Verhältnis der beiden Sendungszähler verrät, wie oft Sie bei jeder Person nachgefasst haben – eine Zahl, die sonst nirgends auf der Plattform auftaucht. ### Bei denen nachfassen, die nicht abgeschlossen haben Ein eingebettetes Formular hat keine Liste der Nicht-Antwortenden, weil es keine Versandliste hat. Das Nachfassen muss also auf der anderen Seite nachgebaut werden: ein **geplanter Prozess über die angelegten Datensätze**, der eine Erinnerung an die sendet, die den Zustand „beworben“ erreicht haben und nie den Zustand „abgeschlossen“. Das ist die strukturelle Lehre des ganzen Blueprints. Jede Messung, die ein eingebettetes Formular Ihnen nicht liefern kann, muss als Reporting über die Datensätze rekonstruiert werden, die es angelegt hat – was nur möglich ist, weil §4 auf einem Untertyp, einem Herkunftsfeld und einem Registrierungsdatum bestanden hat. Auf diese drei Felder filtert der Nachfassprozess. Lassen Sie sie bei der Anlage weg, lässt sich das Nachfassen überhaupt nicht bauen. ### Die Familie lesbar halten Ein solcher Funnel kommt schnell auf mehrere Prozesse: die Bewerbung bestätigen, auf die Unterschrift reagieren, bei den Nicht-Unterzeichnern nachfassen, den Bewerber bewerten, die Kampagne fahren. Es sind getrennte Prozesse, weil ein Prozess einen Filter trägt, dessen Zweige nach dem Prinzip „der erste Treffer gewinnt“ arbeiten, und diese Bedingungen alle gleichzeitig zutreffen können – die Einschränkung und die Benennungsdisziplin stehen in [Blueprint 011](https://blueprints.coevera.com/de/blueprints/keeping-hundreds-of-automations-maintainable/). Binden Sie jeden an die konkreten Formular-IDs, die er bedient; ein Trigger nimmt eine **Liste** von Formularen, sodass eine Familie nahezu identischer Formulare sich einen einzigen Prozess teilen kann, statt ihn zu vervielfachen. ## 06 · Grenzen & Kompromisse > **Ein eingebettetes Formular kann von der Plattform nicht gemessen werden.** Die Rücklaufquote > ist Antworten ÷ eindeutige Empfänger, und ein eingebettetes Formular hat keine Empfänger – also > ist die Quote leer und die Liste gesendet und nicht beantwortet leer, egal wie viele Leute etwas > übermitteln. Das ist Arithmetik, kein Bug, und keine Einstellung ändert daran etwas. - **Eine Pflichtfrage kann ins Leere gehen.** Am Live-Formular verifiziert: Die Datenschutz-Checkbox ist für die Übermittlung Pflicht und fehlt in der Anlagevorlage, sodass die Einwilligung auf der Antwort erfasst wird und nicht auf dem Kontakt. Dasselbe Schweigen gilt für jede Frage, die niemand zugeordnet hat – die Antwort ist gespeichert, und sie steht nicht auf dem Datensatz. - **Ein Upsert über die E-Mail-Adresse ist ein Schreibweg, dessen Schlüssel ein erratbarer Identifikator ist.** Wer eine bekannte Adresse übermittelt, aktualisiert den Datensatz dieser Person. Bei einem Formular für den Erstkontakt ist dieses Risiko meist vertretbar, weil die beschreibbaren Felder ohnehin die sind, die dieser Person gehören – aber es ist eine Entscheidung, kein Standard, und es ist derselbe Mechanismus, der bei Umfragen in [Blueprint 012](https://blueprints.coevera.com/de/blueprints/customer-survey-answers-onto-the-record/) als Gefahr markiert ist. Wo das Formular etwas kommerziell Bedeutsames aktualisiert, gleichen Sie auf einen Wert ab, den nur die vorgesehene Person haben kann. - **Dieselbe Einstellung ist in einem Design richtig und in einem anderen falsch.** Wiederholte Antworten nicht zu beschränken, ist es, was den Upsert hier funktionieren lässt; bei einer versendeten Umfrage ist es das, was die Rücklaufquote über 100 % treibt. Es gibt keinen sicheren Standard – entscheiden Sie pro Formular, welches der beiden Sie bauen. - **Die Zahl der Pflichtfelder sind Konversionskosten, die Sie nicht sehen können.** Neun Pflichtfelder einschließlich einer vollständigen Postanschrift sind viel verlangt von einem Fremden, und Abbrüche passieren in einem Frame, den die übergeordnete Seite nicht beobachten kann. Sie sehen die Übermittlungen, die abgeschlossen wurden, und nie die, die es nicht wurden, sodass über diesen Kompromiss nachgedacht werden muss, statt ihn zu messen. - **In einem iframe ist das Formular für Crawler und für Besucher ohne JavaScript unsichtbar**, und sein Inhalt kann nichts vom Such- oder Zitiergewicht der Seite tragen. - **Nichts schränkt ein, wer es einrahmen darf.** Kein frame-ancestors, kein X-Frame-Options – die Eigenschaft, die das Einbetten trivial macht, bedeutet auch, dass das Formular auf jeder Website funktioniert, die die Link-ID kennt, und die Link-ID steht in Ihrem Seitenquelltext. - **Als Freitext getippte Herkunft driftet**, unbemerkt und dauerhaft. Zwei Herkunftsmechanismen auf einem Live-Formular widersprechen sich bereits. - **Die Eigentümerschaft ist aufgeschoben, nicht gelöst.** Der festgelegte Eigentümer stellt die Plattform zufrieden und weist die Arbeit niemandem zu. Ein Routing-Prozess oder eine gemeinsame Ansicht ist eine eigene Aufgabe, und wer sie vergisst, bekommt ein Erfassungsformular, das eine Warteschlange füttert, die kein Mensch öffnet. - **Felddefinitionen werden im ganzen Space geteilt.** Identische Feldkennungen erscheinen auf voneinander unabhängigen Formularen im selben Space. Praktisch für die Wiederverwendung; wie sich eine Bearbeitung ausbreitet, wurde nicht getestet, behandeln Sie das Umbenennen einer geteilten Frage also als Änderung an jedem Formular, das sie nutzt, bis das Gegenteil bewiesen ist. ### Der Kompromiss, den man offen aussprechen sollte Das Formular im CRM zu hosten, bringt das, was am meisten zählt und sich am schwersten nachrüsten lässt: Die Website weiß nichts mehr über Ihr Datenmodell. Fragen ändern sich ohne Release, keine Zugangsdaten verlassen das CRM, und der Datensatz kommt typisiert, mit Eigentümer und gestempelt an. Was Sie aufgeben, ist alles, was davon abhängt, das Formular als Teil Ihrer Seite zu sehen – visuelle Integration über das eigene Styling des Formulars hinaus, Funnel-Analysen zu einzelnen Feldern, indexierbarer Inhalt und ein Formular, das ohne JavaScript funktioniert. Für ein Anmeldeformular hinter einem Button ist das ein guter Tausch. Für ein Formular, das die Landingpage *ist*, ist es das nicht, und die ehrliche Antwort dort ist eine von Hand gebaute Seite, die an die API sendet und die Wartungskosten in Kauf nimmt, die §2 beschreibt. ## 07 · Verifizierung Ausgelesen am 2026-09-10 aus einem Live-Produktiv-Space und der öffentlichen Live-Seite, die das Formular einbettet – ein Bewerbungsformular für ein Partnerprogramm, das seit April 2026 im Einsatz ist. - **Die Kopplung wurde von beiden Enden aus verifiziert.** Die in der Formulardefinition gespeicherte Link-ID ist byte-identisch mit der ID in der URL, die das Inhaltsmodell der öffentlichen Seite hält, und dieses hält genau zwei Schlüssel für das Formular: diese URL und einen barrierefreien Titel. - **Der öffentliche Endpunkt wurde abgerufen.** Er liefert HTTP 200 mit einer HTML-Hülle von ~1,7 KB, die ein benutzerdefiniertes Element und drei Modul-Skripte von einem statischen CDN enthält, und ohne Header `X-Frame-Options` oder `frame-ancestors` – das ist die Grundlage jeder Aussage zum Einbetten in §3. - **Der Upsert wurde an seinen eigenen Zählern bestätigt:** 49 Antworten, 41 Datensätze in der Kategorie beantwortet, 0 unbekannte Antwortende. Acht Übermittlungen wurden also einem bestehenden Datensatz zugeordnet, statt einen anzulegen, und nichts fiel unzugeordnet durch. - **Einstellungen und Anlagevorlage wurden wörtlich ausgelesen** – die drei Upsert-Flags, das Autolink-Paar, der Untertyp, die festen IDs für Eigentümer und Einheit, beide Herkunftsstempel und das Fehlen jedes Einwilligungsfelds. Dass die Vorlage alle fünf Telefon- und fünf E-Mail-Plätze aufzählt, belegt, dass sie eine vollständige Nutzlast und kein Patch ist. - **Der Feldsatz wurde vollständig ausgelesen:** elf Fragen, neun davon Pflicht, Vorbefüllung bei jeder aus, die Frage nach der Straße ein Textbereich, wo ihre Geschwister einzeilige Eingaben sind. - **Die Automatisierung wurde nachverfolgt:** ein Prozess, allein an diese Formular-ID gebunden, Trigger-Entität die Antwort und Datensatztyp der Kontakt, zwei Knoten. Sein letzter Laufzeitstempel liegt etwa acht Sekunden nach dem letzten Antwortzeitstempel des Formulars. - **Die Funnel-Zahlen wurden aus den eigenen Zählern der beiden Formulare gelesen**, und die 85,4 % ergeben sich exakt als 35 ÷ 41 – dieselbe Arithmetik Antworten durch eindeutige Empfänger, die über einen ganzen Bestand in [Blueprint 012](https://blueprints.coevera.com/de/blueprints/customer-survey-answers-onto-the-record/) verifiziert wurde. **Nicht beobachtet, und als solches benannt:** - Eine eigens dafür vorgenommene Übermittlung. Jeder Befund stammt aus gespeicherter Konfiguration, gespeicherten Ergebnissen und dem öffentlichen Endpunkt – nicht aus Testdaten, die durch ein Live-Formular geschickt wurden. - Ob sich die Bearbeitung einer geteilten Formularfelddefinition auf die anderen Formulare auswirkt, die sie nutzen. - Ob ein leerer Wert in der Anlagevorlage leer schreibt oder übersprungen wird. - Das Verhalten von reCAPTCHA selbst; nur, dass es ein Flag pro Formular ist, bei diesem Formular aus und bei einem anderen im selben Space an. ### Was auf eine Regression hindeuten würde - **Unbekannte Antwortende über null** bei einem Upsert-Formular bedeuten, dass das Autolink-Paar kaputt ist – und weil das Anlegen weiter funktioniert, wirkt es wie ein gesundes Formular, das Datensätze erzeugt, die niemand findet. - **Die Zahl der Datensätze wächst im Gleichschritt mit der Zahl der Antworten.** Bei einem Formular mit wiederkehrenden Einsendern bedeutet ein Datensatz pro Antwort, dass der Abgleich nicht mehr stattfindet und sich Duplikate ansammeln. - **Antworten gehen ein, während die Bestätigung ausbleibt.** Die Bestätigungsseite verspricht weiterhin eine E-Mail; Versprechen und Prozess werden an verschiedenen Stellen konfiguriert, und nichts verbindet sie. - **Die Zahl der Datensätze des festgelegten Eigentümers wächst, ohne dass der Nachfassprozess läuft.** Das ist die Signatur eines Erfassungsformulars, das eine Warteschlange füttert, die niemand bearbeitet. ## Verwandte Blueprints - [Blueprint 012 — Wie führen Sie eine Kundenumfrage aus Ihrem CRM durch und bekommen die Antworten zurück an den Datensatz?](https://blueprints.coevera.com/de/blueprints/customer-survey-answers-onto-the-record/) — das Datenmodell der Onlineformulare, Vorbefüllung und Autolink für bekannte Kunden und die Arithmetik der Rücklaufquote. - [Blueprint 011 — Wie halten Sie Hunderte von CRM-Automatisierungen wartbar?](https://blueprints.coevera.com/de/blueprints/keeping-hundreds-of-automations-maintainable/) — warum ein Erfassungs-Funnel zu mehreren Prozessen wird und wie man sie benennt. - [Blueprint 003 — Wie modellieren Sie etwas, für das Ihr CRM kein Objekt hat?](https://blueprints.coevera.com/de/blueprints/where-should-this-data-live/) — die Entscheidung, zu welcher Entität eine öffentliche Übermittlung werden soll. - [Blueprint 001 — Wie führen Sie fünf verschiedene Arten von Kundenanfragen durch einen einzigen Helpdesk?](https://blueprints.coevera.com/de/blueprints/one-entity-five-request-types/) — das Unterscheidungsmerkmal Untertyp, das die Anlagevorlage setzt. - [Blueprint 005 — Wie migrieren Sie Kontakte aus einem anderen System, ohne unbemerkt Daten zu verlieren?](https://blueprints.coevera.com/de/blueprints/contact-migration-without-data-loss/) — warum die E-Mail-Adresse bei großen Mengen ein fragiler Deduplizierungsschlüssel ist. ## Häufige Fragen ### Wie fügen Sie Ihrer Website ein Kontaktformular hinzu, das direkt in Ihr CRM schreibt? Das CRM hostet das Formular, und die Website bettet es ein. Jede Formulardefinition trägt eine Link-ID, und das öffentliche Formular liegt unter einer URL, die aus dieser ID gebildet wird; die Seite hält nur diese URL und einen barrierefreien Titel, sodass es auf der Website kein Formular-Markup, keine Feldliste und keinen API-Schlüssel gibt. Werden Create-Record, Update-Record und Autolink gemeinsam aktiviert, wird eine Übermittlung zu einem Upsert: Die übermittelte E-Mail-Adresse wird mit dem E-Mail-Feld des Kontakts abgeglichen, sodass ein wiederkehrender Bewerber seinen eigenen Datensatz aktualisiert, statt einen zweiten anzulegen. ### Wie verhindern Sie, dass ein öffentliches Formular doppelte Datensätze anlegt? Aktivieren Sie Autolink zusammen mit Create-Record und Update-Record. Autolink nennt ein Formularfeld und ein Datensatzfeld; wenn eine Übermittlung zu einem bestehenden Datensatz passt, aktualisiert sie diesen, und nur eine nicht zugeordnete Übermittlung legt einen neuen an. Bei einem Live-Bewerbungsformular reduzierte das 49 Übermittlungen auf 41 verschiedene Personen, ohne nicht zugeordnete Antworten. ### Warum zeigt ein eingebettetes Formular keine Rücklaufquote? Weil die eingebaute Rücklaufquote Antworten geteilt durch eindeutige Empfänger ist und ein eingebettetes Formular keine Empfänger hat. Seine Sendungszahl ist null, also ist der Divisor null und die Quote leer, egal wie viele Leute etwas übermitteln. Dasselbe gilt für die Liste gesendet und nicht beantwortet, sodass ein eingebettetes Formular auch keine native Nachfassliste hat – beides muss als Reporting über die Datensätze nachgebaut werden, die es angelegt hat. ### Wird eine verpflichtende Einwilligungs-Checkbox in einem Formular zu einem Feld auf dem Datensatz? Nur wenn Sie sie zuordnen. Eine Datenschutz-Checkbox kann für die Übermittlung verpflichtend sein und trotzdem in der Vorlage zum Anlegen des Datensatzes fehlen; dann überlebt die Einwilligung nur auf dem Antwortdatensatz und in dessen angehängtem PDF und lässt sich auf dem Kontakt nicht abfragen. Jede Einwilligung, die Sie filtern oder massenhaft nachweisen müssen, muss ausdrücklich einem eigenen Feld zugeordnet werden. ### Wem gehört ein Datensatz, den ein anonymer Website-Besucher angelegt hat? Dem, den Sie in der Anlagevorlage festlegen. Jeder Datensatz braucht einen Eigentümer und eine Vertriebseinheit, und eine anonyme Übermittlung liefert keines von beiden, also trägt die Vorlage feste IDs. Die Zuweisung an eine echte Person ist daher ein eigenes Thema – ein Routing-Prozess oder eine gemeinsame Ansicht über die Datensätze des festgelegten Eigentümers, nicht etwas, das das Formular entscheiden kann. --- Herausgegeben von Coevera. Auf das wiederverwendbare Muster abstrahiert – keine Kundennamen, keine Kundendaten, keine personenbezogenen Daten.