A healthcare clinic and an online store don’t track the same things about a customer. VeloConnect ships with the common fields — name, phone, email, tags, opt-in — and lets you add whatever else your business actually needs.
A few that real teams have built:
- A barbershop:
preferred barber(single-select) - An e-commerce shop:
last order value(number),loyalty tier(single-select) - A SaaS team:
account stage(single-select),MRR(number) - A clinic:
patient ID(text),last appointment(date),insurance carrier(single-select)
Where to add them
Settings → Contact fields is admin-only. Anyone can view custom fields once they’re added — the admin gate is on schema changes, not data.
Field types
| Type | When to use |
|---|---|
| Text | Anything free-form: notes, IDs, short answers |
| Number | Counts, amounts, scores. Format and decimals are configurable |
| Date | A single calendar date — no time component |
| Boolean | Yes/no flags. Renders as a switch on the contact profile |
| Single-select (dropdown) | A short list of mutually exclusive options |
| Multi-select | A list where more than one can be true |
You can change a field’s name, instructions, and required/optional flag later. You cannot change its type without deleting and re-creating the field — type changes would invalidate existing data.
Visibility
Each field has a visibility setting:
- Agents and above — the default. Everyone who can see the contact can see this field.
- Admins only — useful for internal tags (“VIP escalation path”, “compliance hold”).
The admins-only setting still lets the field power filters and exports the admin runs; agents just don’t see it on the profile.
Required vs optional
A required field has to have a value before a contact can be saved. Be careful with this on existing contacts — turning a field required after contacts exist means those contacts can’t be edited until the field is filled.
A practical pattern: add new fields as optional, let the data accumulate from real workflows for a few weeks, then promote to required once you’re sure the field is well-defined.
What custom fields can do once they exist
- Show up on the contact profile alongside the built-ins.
- Power filters in the Contacts list (“show me everyone whose
account stageisqualified“). - Appear in CSV exports so analytics tools can use them.
- Read and write via the API — same shape as built-in fields.
- Drive sender selection in campaigns (e.g. only send to contacts with a non-empty
phonefield — this is automatic; the campaign step explains how it works).
A note on naming
Pick short field names. They show up in narrow columns on the contact list, in filter dropdowns, in the CSV export header. “Last order value (USD)” is fine; “What was the customer’s last order value in US dollars including tax” is not.
Use lowercase, plain English. Avoid emoji. Avoid (internal) parenthetical asides — use the visibility setting instead.
Deleting a field
Deleting removes the field definition and the data. The deletion is logged in the audit log so you can prove who removed it and when, but the data is gone. For sensitive fields with regulatory implications, prefer making the field admins-only and stopping collection, rather than deleting outright.