Migrating off identity fields

Before contacts, a lead’s name and contact details were pool fields — Tabellenschema fields typed firstName, email, phone and so on, or email/phone Custom Fields. Those fields are now inert: values in them are kept, but nothing reads them. The lead’s identity is its contacts.

What that means per surface

Surface	Before	Now
Lead pool columns	Name / E-Mail / Telefon fields	Hauptkontakt and Teilnehmer columns, built from the contacts. Old identity fields are hidden from the column picker.
Custom Fields	Types email and phone available	No longer offered for new fields.
Forms	Fields mapped to pool columns	Fields mapped to people — see Contact mapping. A form without it creates leads with nobody on them.
Webhooks / Connect API	Identity keys in data	A contacts array — see Ingress → Stating who is on a lead. Identity in data is stored and ignored.
Automations	tableEntry.data.firstName, email/phone Custom Fields	$contact.*, $subjects.*, $attendees.* — see Variable placeholders.

Checklist for an existing org

1. Forms: open Formulare. Any form badged Keine Kontakt-Zuordnung needs its fields mapped to people, then republish.
2. Automations: the automations list badges flows with “N × alte Kontakt-Variablen”. Replace each flagged placeholder with the matching contact variable and republish.
3. Integrations (Make, Zapier, custom webhooks): make sure each sender posts a contacts array. A sender that still only puts names in data produces leads with nobody on them — and the ingress webhook doesn’t log that anywhere else.

What happens to the old values

They stay stored on existing leads and are not deleted. They are not kept in step: editing or merging a contact never touches them. Don’t build anything new on them.