Address Fields

The Address field is a dedicated structured field type for capturing postal addresses. Unlike a free-text input, it stores every component of the address (street, house number, postcode, city, state, country, country code, latitude, longitude) as a single JSON object, so Leadflip can filter, route, export, and template against any individual sub-field as if it were its own column.

Migrating from the old Location specialization? The legacy "Text → Location" specialization has been removed. Create new address fields as the Address base type instead. Existing lead data is unaffected by the removal.

When to use an Address field

• You want to filter or route leads by postcode, city, or state (e.g. a partner only wants Bavarian leads).
• You want to personalize emails or webhooks with individual address parts ("Hi Stefan, your roof in 10115 Berlin…").
• You want users to search for their address via autocomplete rather than typing each field separately.
• You want to combine address capture with a map-based Lot Marker (drawing a property boundary auto-fills the address).

If you just need a single line of free text, use a regular Text field instead.

Adding an Address field

1. Go to Entities → select your Entity → Edit → Fields.
2. Click Add Field (or the "+" tile under Advanced in the Form Builder).
3. Pick Address as the base type.
4. Give it a label (e.g. "Wohnadresse", "Projektstandort", "Lieferadresse") and save.

You can have multiple address fields on the same Entity. Typical example: one "billing address", one "delivery address".

Per-form configuration

Once an address field is on a form, click it on the canvas to open the Field Config drawer. The 📍 Address Settings accordion is specific to address fields:

Show address search box

Toggles the OSM-backed autocomplete. When enabled, the user can type "Musterstr. 12 Berlin" and pick the right hit from a dropdown, and Leadflip fills every sub-field at once. When disabled, only the sub-field inputs are shown.

Visible sub-fields

A six-checkbox grid for Straße, Hausnummer, Postleitzahl, Stadt, Bundesland, Land. Untick anything you don't want to collect.

Common patterns:

• Postcode-only funnel: untick everything except Postleitzahl. Combined with Auto-enrich postcode (below), users only need to type their PLZ and the city / state / country fill in automatically.
• Search-only flow: uncheck every sub-field and rely on the search box. Users see one clean autocomplete input.
• Full edit: keep all six checked, useful for CRM drawer editing or detailed registration forms.

Auto-enrich postcode

When on, a postcode-only input is expanded server-side on save: Leadflip calls OpenStreetMap, takes the first hit for that PLZ, and fills in city / state / country / center latitude / longitude.

Use this whenever you build a postcode-only funnel. Your distribution rules can then route by city / state even though the user only typed a PLZ.

If the user already provides a city, country, or coordinates, the enricher skips the field (it never silently overwrites what the user typed).

Linked Lot Marker

When the same form has a Lot Marker field (interactive map for drawing a property boundary), you can link it to this Address field. Two things happen automatically:

1. When the user draws a polygon or drops a pin, Leadflip reverse- geocodes the location and writes the resulting address into this field.
2. If the address field already has coordinates (from a previous step or autocomplete), the Lot Marker uses them as initial map center.

The link is 1:1 and can be set from either side: on the Address field ("Link to Lot Marker") or on the Lot Marker ("Linked Address Field").

CRM display

How the address renders in the CRM lead drawer:

• Formatted line + sub-fields (default): one-line summary at the top, every populated sub-field underneath, "Auf Karte anzeigen" link if coordinates are present. Best for read-heavy + editing.
• Formatted line only: just the one-liner. Click Adresse bearbeiten to reveal the sub-field inputs. Best for compact CRM views.
• Sub-fields only: no header. Useful when postcode and city are the primary data points.

The display mode is purely visual. Under the hood, every sub-field is always available for filters, distribution, exports, and template variables, regardless of which mode you pick.

What gets stored

The address is stored as a JSON object on the lead. Example:

{
  "formatted":     "Musterstraße 12, 10115 Berlin, Deutschland",
  "street":        "Musterstraße",
  "house_number":  "12",
  "postcode":      "10115",
  "city":          "Berlin",
  "state":         "Berlin",
  "country":       "Deutschland",
  "country_code":  "de",
  "lat":           52.5320,
  "lng":           13.3850,
  "source":        "search"
}

The source value tracks how the address was captured: search (user picked from autocomplete), manual (typed sub-fields), linked_marker (came from a linked Lot Marker), or enriched (expanded from a postcode-only input).

Using sub-fields in distribution, filters, and templates

Every sub-field is automatically exposed as its own column:

Distribution routing rules (Settings > Distribution > Partner Filters):

• Wohnadresse / Land equals Deutschland
• Wohnadresse / Postleitzahl is one of 10115, 10117, 10119
• Wohnadresse / Bundesland equals Bayern

CRM advanced filters (any pipeline view, "Filters" sidebar): same options as above.

Email templates / webhook bodies / automation actions:

Hi {{ lead.first_name }},
your project at {{ lead.wohnadresse.formatted }} in
{{ lead.wohnadresse.postcode }} {{ lead.wohnadresse.city }}
will be picked up by our team in {{ lead.wohnadresse.state }}.

Both the root token ({{ lead.wohnadresse }} → the one-liner) and every sub-field ({{ lead.wohnadresse.postcode }}) are available in the variable picker.

Encryption

Just like every other field, you can toggle Encrypt this field at rest under the Rules tab. Be aware that encrypted address fields cannot be filtered or routed by sub-field, because the database cannot read inside an encrypted JSON column. Use encryption for sensitive address data that doesn't need to drive routing, and leave it off when partner targeting depends on the postcode/city/state.

API intake

When sending a lead via the API (POST /api/intake, POST /api/leads, or POST /api/leads/bulk), an address field accepts three shapes:

// Preferred: structured object
{ "wohnadresse": { "postcode": "10115", "city": "Berlin" } }

// JSON string: defensively decoded
{ "wohnadresse": "{\"postcode\":\"10115\"}" }

// Free text: wrapped into { formatted: <input>, source: 'manual' }
{ "wohnadresse": "Musterstraße 12, Berlin" }

Unknown sub-keys are rejected with a 422. Non-numeric lat/lng values are rejected. If the field has Auto-enrich postcode on, a postcode-only payload is expanded server-side before the lead is saved.

See also

• Managing Fields: how to add, edit, reorder, and delete any field type.
• Field Encryption: the encryption trade-off in detail.
• Duplicate Detection: why structured fields like Address aren't usable as match keys (use a scalar sub- field instead).