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
firstName, lastName, childFirstName, name — the canonical identifier fields	Tabellenschema (Custom Fields don’t support these special types yet)
email, phone — anything you want available consistently across multiple pools	Global Custom Fields
kurs, terminwunsch, enum-typed fields, free-text notes	Global Custom Fields
Any field of email or phone type	Global Custom Fields (special types let the lead-detail view render mailto: / tel: links automatically)

In short: identity fields → Tabellenschema; everything else → Custom Fields.

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	A handful of recognized special types: firstName, lastName, childFirstName, name. Plus generic text/number types. The special types are what lets RocketLead auto-compose a lead’s display name.
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 Settings → Custom Fields (or via the “Custom Fields” link inside a pool’s field configuration). 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, email, phone, url, enum. The type drives input validation and special rendering (e.g. email makes the lead-detail view show a clickable mail link).
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:

• Add support for firstName / lastName / childFirstName / name as Custom Field types.
• 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.

New setups built today should use Custom Fields for everything except the identifier fields. Once the identifier-type support lands in Custom Fields, the Tabellenschema view is going away.

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.