Tabellenschema vs. global Custom Fields

A Lead Pool’s columns come from two parallel systems:

1. Tabellenschema — fields defined directly on a single Lead Pool. Old model.
2. Global Custom Fields — fields defined org-wide and linked into one or more Lead Pools. New model.

Both currently work; they coexist in the UI; the migration plan is to consolidate everything onto Custom Fields by end of 2026. New setups should prefer Custom Fields wherever possible.

When to use which

Use case	Use
Names, phone numbers, email addresses	Neither. Identity lives on the lead’s contacts, not in the pool’s schema — see below
kurs, terminwunsch, enum-typed fields, free-text notes	Global Custom Fields
Anything you want available consistently across multiple pools	Global Custom Fields
A question only one pool asks	Tabellenschema, or a Custom Field linked to that pool alone

In short: who the lead is → contacts; what they asked → Custom Fields.

Identity is not a field any more

Fields typed firstName, lastName, childFirstName, name, email or phone still exist on older pools and keep their historical values, but nothing reads them. A name written into one does not name the lead, does not reach automations and is not what the console shows. Who a lead is comes from the contacts attached to it — stated by the sender, or entered in the console.

Those columns are hidden from the pool’s field picker for that reason. Don’t create new ones.

Tabellenschema (per-pool)

These fields live on the Lead Pool itself and are configured from the pool’s Settings view.

Each field has:

Property	Notes
Key	The raw key used when posting data via the Ingress webhook or referencing the field in automations. Stable.
Label	The display name in the console. Editable any time.
Type	Generic text/number types. The identity special types (firstName, lastName, childFirstName, name) are retired — they survive on older pools but nothing reads them.
Primary (star icon)	Set when you have multiple fields of the same type and want one designated as canonical. Mostly historical — rarely needed today.

Reading the value of a Tabellenschema field in an automation: {{<triggerNodeId>.tableEntry.data.<key>}}.

Global Custom Fields (org-wide)

These live at Einstellungen → Felder (or on a pool’s Felder tab, below its own fields). They’re defined once for the org and then linked into the Lead Pools that should expose them.

Each field has:

Property	Notes
Name	The display label. Used wherever the field appears.
Type	One of text, number, boolean, date, datetime, time, url, enum. The type drives input validation and special rendering. email and phone fields are no longer offered: phone numbers and email addresses belong to the lead’s contacts.
Linked pools	Which Lead Pools expose this field. Adding a pool later is a single click.
Options (enum type)	Predefined values for enum (dropdown) fields, used by the free-text → enum migration tool.

Reading the value in an automation: {{<triggerNodeId>.tableEntry.customFieldData.<custom-field-uuid>}}. Note customFieldData, not data — the variable picker in the editor inserts the right path automatically.

The deprecation plan

The 2026 consolidation will:

• Migrate every Tabellenschema field on every existing pool into the Custom Fields registry (with the same key + label, no operator action needed).
• Remove the per-pool field-config view; the only configuration surface becomes Custom Fields.

The identifier types are not part of that migration: identity moved to contacts instead, so there is nothing to carry over. New setups built today should use Custom Fields for everything the pool asks, and state who the lead is in contacts.

What’s next

• Bootstrap the pool schema via the Ingress webhook — the fastest way to seed fields for a new pool.
• Migrate a free-text Kurs field to a dropdown.