Custom fields

LeadHunter ships with the obvious fields — name, website, phone, address, status — but every business tracks attributes specific to its market. Custom fields let you define those once, attach them to every account in your company, and reference them in account forms, the Accounts list filters, saved filters, campaign bulk-add, imports and exports.

Custom fields are scoped to a project — a bike-shop project’s fleet_size is invisible to a podcast-directory project; neither project’s schema pollutes the other’s data.

Field types

Type	What it stores	Example
`text`	Short single-line string	License number
`textarea`	Long multi-line string	Notes about the location
`number`	Integer or decimal	Number of franchises
`date`	YYYY-MM-DD	Contract renewal date
`boolean`	true / false	Has loyalty program?
`select`	One value from a list	Tier: Gold / Silver / Bronze
`multiselect`	Many values from a list	Languages spoken
`url`	Validated URL	Reviews page

text, textarea and url values hold at most 10,000 characters. A longer value is refused with an error on that field (“At most 10,000 characters”), so paste long documents somewhere else and link to them. Every account carries its custom fields in each list and export, so a cap keeps those fast.

Picking the right type

A quick decision guide for which type to reach for:

You want to capture…	Use
One label from a finite list (Gold / Silver / Bronze)	`select`
Many labels from a finite list (multi-tag)	`multiselect`
A yes/no flag	`boolean`
A count you’ll want to filter or sort by	`number`
A specific date	`date`
A clickable URL	`url`
A short opaque string (license number, account ref)	`text`
A long free-form blob	`textarea` (but consider: would `notes` on the Account itself do?)

Picking the most-restrictive type that fits makes the field usable in saved filters with the right operators. text is the catch-all, but a select would let you filter cleanly while text only supports substring matching.

Anatomy of a definition

From Settings → Custom fields → Add field, each definition carries:

Property	What it does
Key	Machine name. Lowercase, snake_case, starts with a letter (regex `^[a-z][a-z0-9_]{0,79}$`). Shows up in filter expressions as `cf.<key>`.
Label	Human-readable name shown on account forms (e.g. “Fleet size”).
Type	One of the eight above.
Product scope	Optional. Leave it on Project-wide and the field shows on every account; pick a product and the field is grouped under that product on the account screens. Handy when a field only makes sense for one product line.
Options	Required for `select` / `multiselect`. The exact strings counted as valid values.
Deep-link template	`url` fields only — turns the field into a one-click link into an external system. See Deep links into external systems.
Help text	One-line hint shown next to the input on the account form.
Required	When on, account create / edit forms reject submissions that don’t fill this field. Partial updates skip the check, so a re-import that omits the field doesn’t fail.
Order	Display position on account forms. Lower numbers appear first.

The schema is per-project, not global. A field defined under Bike shops doesn’t show up under Radio stations — each project’s fields are isolated, even inside one organization. Within a project you can narrow a field further to a single product with Product scope — the value still lives on the account, the product is just how it’s grouped in the UI.

How values land on accounts

Two paths an operator can use:

The account form — every defined field shows up in the Custom fields section of the new-account form and in the Custom fields card on the account page’s Profile tab, in the order you set. Validates on save against the declared type.
CSV / XLSX import — map a column to a custom field key in the import wizard’s column-mapping step. The static-values trick from Import accounts also works here: set a batch-wide custom-field value (e.g. every row in this file is cf.source_list = "Trade show 2026") without needing a column for it.

Auto-enrichment doesn’t fill custom fields. The discover-website + scrape + language-detect pipeline only populates the standard fields (website, language). If you need a custom field populated automatically, fill it on import or on the account form.

Deep links into external systems

A url field can be more than a place to paste a link. Give it a deep-link template and LeadHunter builds a one-click link into your CRM, billing system, admin panel — anywhere an account also lives — without anyone pasting a URL per row.

You write the template once, with {placeholders} LeadHunter fills in per account:

https://crm.example.com/contact/{imported_id}
https://your-admin.example.com/client/{value}

Three kinds of placeholder:

Placeholder	Filled with
`{value}`	A value the operator types into this field on the account (use this once per template).
`{cf.<key>}`	The value of another custom field on the same account.
Account fields	The account’s own data — `{imported_id}`, `{id}`, `{website}`, `{email}`, `{phone}`, `{name}`, `{city}`, `{country}`, `{google_place_id}`.

The standout is {imported_id}. When you import a list, LeadHunter remembers each row’s original ID from the source system. A template like https://crm.example.com/contact/{imported_id} then deep-links every imported account straight back into that system — no per-account typing at all. That’s the quickest way to make LeadHunter a launchpad into the tools your team already uses.

Set it up in Settings → Custom fields → Add field:

Choose type URL.
Fill Deep-link template with your URL and placeholders. A live preview shows what the link will look like.
Optionally set a Link label (e.g. “Open in CRM”, “Enacast admin”) — that’s the text shown instead of a raw URL. It falls back to the field’s label.
Optionally set Product scope if the link only applies to one product.

On each account, the field renders as a labelled, clickable link that opens in a new tab. If the template needs a {value}, you’ll see an input to type it; if it’s built entirely from account data, there’s nothing to fill — the link just appears. When a referenced piece of data is missing on an account (e.g. a row with no imported ID), no broken link is shown for that account.

A few practical notes:

Safe by design — templates must point at an http(s) web address with a fixed host (e.g. https://crm.example.com/…); placeholders go in the path or query string, not the host. Values you type are encoded into the link so odd characters can’t break it.
Plain URL fields still work — leave the template blank and the field behaves like before: paste a whole URL and it renders as a link.
Exports include the built link — when you download a campaign’s accounts as CSV, a deep-link column carries the finished URL, ready to hand to another tool.
One manual value per field — if you need two different external IDs on the same account, make two fields.

The other direction shipped: webhooks. Deep links take you into the other system; outbound webhooks send data the other way — notifying your external system the moment an account is created, changes status, or replies. Pulling state back (full two-way sync) is the remaining roadmap step.

Custom fields and scoring

Custom fields are for segmenting and targeting: they decide which accounts go into a list, a ranking run or a campaign. The fit score itself doesn’t read them today. The scoring model reads the account’s name, location, business type, specialization, website and its text, language, email and phone, and the start of its notes.

So when a custom field’s value should move the score (a bike shop with a workshop is a better fit), either filter on it before you rank or score (rank only the shops where cf.service_offered is true), or say it in a field the model reads, such as the business type or specialization. See Account → Notes.

Filtering and segmentation

Reference custom fields in saved filters with the cf. prefix:

match: all
conditions:
  country = Spain
  cf.tier in [Gold, Platinum]
  cf.contract_renewal_date lt 2026-06-30

Custom fields support the same operators as built-ins, modulo the field type — gt / lt apply only to numbers and dates; is_true / is_false only to booleans; contains differs between text (substring) and multiselect (array membership). See Build a saved filter for the full operator matrix and worked examples.

How custom fields interact with merges

When two accounts merge, custom fields are unioned:

text / textarea / number / date / url / select / boolean — if only one row has a value, that value sticks; if both have values, the survivor’s wins but the absorbed row’s value is recorded in merge_history so you can read what was overridden.
multiselect — union of both arrays. No loss.

Nothing is silently dropped, even on a conflict.

Adding, renaming, deleting

Action	Effect
Add a field	Instant. Existing accounts immediately gain the field with a null value; new accounts pick it up on the next form load.
Rename label or help text	Instant. Filters and forms keep working — they reference the key, not the label.
Rename a key	Not safe. References in saved filters and import mappings break silently. Prefer creating a new field with the new key, backfilling values, then deleting the old one.
Delete a field	Removes it from the schema (stops showing in forms; rejected by the import wizard). The values stay on existing accounts in the underlying JSON blob — they just become invisible. Cheap to re-add; expensive to recover deleted history. If you’re sure you want the values gone too, ask support for a one-off cleanup.

What’s not a good fit for custom fields

Personal data on individual people — names, emails, phone numbers of specific contacts. Those belong on the Contact model, not on the Account’s custom fields.
High-cardinality free text you never plan to filter on. A 10KB description of every account belongs in notes, not in a textarea custom field — custom fields are meant to be queryable, and JSON-indexed long text doesn’t query efficiently.
Anything that’s the same for every account — that’s a project-level setting, not a field on each row.
Anything you’ll want to aggregate across the whole database — define a custom field that filters cleanly (number, date, select) and use saved filters for the aggregation; the saved-filter reach estimator is the closest thing to a count-by query in LeadHunter today.

Worked example 1 — a bike-shop CRM

For a project running outbound to bike shops, useful custom fields might be:

Field	Type	Why
`fleet_size`	`number`	Target by store size. “Shops with ≥20 bikes in stock” is a meaningful audience.
`brands_carried`	`multiselect`, options = the brands you care about	”Shops that carry Trek but not Specialized” is a meaningful slice.
`service_offered`	`boolean`	Some products only fit shops with a workshop.
`contract_renewal_date`	`date`	For existing customers — filter for “renewing in the next 90 days”.
`loyalty_program_url`	`url`	Useful for partnership campaigns; one click from the row.

A saved filter combining country = Spain + cf.fleet_size gte 20 + cf.brands_carried contains Trek + status = prospect gives you the audience for next quarter’s premium-Trek-dealer campaign.

Worked example 2 — a podcast / radio-station directory

A project running outbound to media outlets might define:

Field	Type	Why
`format`	`select`, options = `news`, `music`, `talk`, `mixed`	The audience is different per format: filter on it before you rank.
`weekly_audience`	`number`	Keep only stations above an audience floor (`cf.weekly_audience gte 5000`).
`genres`	`multiselect`, options = the music genres you care about	”Rock and electronic, but not classical” is a real targeting move.
`accepts_sponsorship`	`boolean`	Hard prerequisite — set it after the first conversation.
`frequency_mhz`	`number`	Geographic + technical filter for FM-only campaigns.

For a “podcast advertising platform for music shows” product, filter the Accounts list to cf.genres in your genres and cf.weekly_audience above your floor, then Rank that list: the model scores only the stations that already pass the hard requirements, using what it reads on each station’s website.