Skip to main content

​
Field schema explorer

Custom fields covers the write side of your contact schema: define a field, choose its type, attach validators, write values. The schema explorer is the read side — the console surface that answers, in one view:
  • Which fields exist — every custom field defined in your organization.
  • What type each one is — text, number, boolean, date, select, multiselect, or user reference.
  • How many contacts have a value — the fill count, per field.
  • What the stored values look like — a representative sample of the most recent values written, PII-redacted.
This page walks the explorer end to end: opening it, searching the schema, reading a field’s detail panel, and interpreting the empty and deleted-field states.

​
What the explorer answers that the custom-fields guide does not

The explorer is a read-only observability panel: opening it never changes a definition or a value. It complements the editor instead of repeating it. The editor tells you what a field may hold (type, options, validators); the explorer tells you what it does hold (fill count, live samples) and who depends on it (segments, campaigns, flows, drip enrollments). Questions it answers in seconds:
  • Before you tighten a validator or narrow a select’s option list, are there stored values the new rule would make illegal? Check the samples first — if they show values you are about to outlaw, retire the field instead of breaking writes for existing data.
  • Which fields are defined but never used, and are therefore retirement candidates?
  • Is the CRM sync actually populating account_owner, or has it been empty for weeks?
None of these have an answer in the editor, because none of them are about the definition.

​
Open the page

In the dashboard, go to Audience → Contact fields (/audience/fields). The Contact fields tile on the Audience hub links to the same page. The page is available to your owner, admin, and developer roles. The page renders fully before you define a single custom field: the search box, the field list, and the detail panel are all present, and the list shows a “No custom fields defined” state with a Create field button that takes you straight to Settings → Custom fields. The built-in contact attributes (name, phone, email, channel preferences) are always present on every contact record; the explorer tracks the custom schema you add on top of them.

​
Search and filter by name or type

The search box filters as you type across each field’s name, key, type, and description. tier finds a field named “Plan tier” with the key plan_tier, and typing select narrows the list to fields of that type, which is the quickest way to audit one type family across the whole schema. The Clear button resets the query. When nothing matches, the list switches to a “No fields match” state and suggests a shorter query or a check of the field key’s spelling.

​
Open a per-field detail panel

Click any row to open the detail panel beside the list. The panel shows three blocks:
  • Definition — the field key, display name, and type, with a Required badge where the field is mandatory and a Not indexed badge where it is excluded from search, plus the description. For select and multiselect fields, the full allowed-options list is shown as chips.
  • Usage — Contacts with value (the fill count), plus the number of Segments, Campaigns, Flows, and active drip enrollments that reference the field, and a combined Total references.
  • Sample values — up to ten of the most recent distinct values stored under the field key. This is the same contract as GET /api/v1/custom-fields/{id}/explorer in the API reference: the most recent distinct values, each PII-redacted before display.
Two behaviors prevent common misreads:
  • Storing a value is not referencing the field. A field can hold values on hundreds of contacts while Segments, Campaigns, and Flows all read 0, because nothing uses it yet. When that is the case the panel says so explicitly instead of leaving unexplained zeros, and the same holds for a field that is defined but completely unused.
  • Samples refresh while you work. New contact writes can push an older value out of the sample window; the panel refetches when you return to the tab so the samples stay current.
Every value is redacted server-side: phone numbers, email addresses, SSNs, and card numbers are replaced with [REDACTED_*] tokens before they reach your screen, and a sample is never displayed alongside the contact it came from. What you see is the shape of the data, not the data’s owners. Two actions sit at the bottom of the panel:
  • Edit field opens the same editor dialog Settings → Custom fields uses; key and type stay locked, exactly as on the settings surface.
  • View contacts with this field jumps to the contact list pre-filtered to contacts that carry a value for the field.
Press Esc to close the panel and return to the list.

​
What triggers the empty and 404 states

  • Freshly created field, zero samples. The sample area reads “No contact currently stores a value for this field”, and the usage block notes that the field is defined but not in use yet. Both are expected states for a new field, not load failures.
  • Every stored value empty or redacted. The sample area says so rather than rendering a blank list, so you can tell “nothing stored” apart from “stored, but nothing displayable”.
  • No search matches. Covered above; clearing the query restores the full list.
  • A sibling admin deletes the field while your panel is open. The panel’s lookup for the deleted field returns a 404; the page closes the stale panel and refreshes the list, so the field disappears from your view instead of lingering as a ghost row.
  • A transient load failure. The list and the panel each carry their own retry. While a retry is in flight the panel keeps the previously loaded detail on screen, so a network blip never blanks what you were reading.

​
The anti-pattern the explorer replaces

Before this surface, the honest answer to “what is stored in this field?” was: export the audience to CSV, open the spreadsheet, grep. That workflow is slow, because a full contact export leaves the platform to answer a one-line question. It is also PII-leaky, because the export carries every contact’s raw phone numbers, emails, and other personal data into a file that lives outside Orbit, where it gets renamed, forwarded, and forgotten in a shared drive. The explorer answers the same question inside the console, from samples your tenant’s server redacts before display. Nothing leaves your organization.

​
When to write vs. when to read

The explorer only reads. To change the schema:
  • Create and edit definitions in Settings → Custom fields (see the console walkthrough), or use the panel’s Edit field button, which opens the same editor without leaving the page.
  • Lifecycle, validators, and safe retirement — dependency scans, forced deletes, and the create-a-replacement-field migration pattern — live in Custom fields.
  • Scripting — everything the explorer shows is available over the API, including GET /api/v1/custom-fields/{id}/explorer; see the Custom Fields API reference.

​
See also