What did HighLevel add to custom fields on October 10, 2026?
On October 10, 2026, HighLevel announced that snapshots and the public API now support its newly launched custom field types: URL, Date & Time, Rich text, Users field, and image support in Radio and Checkbox fields. HighLevel says both are live in production for all accounts.
The source is the HighLevel changelog entry Introducing snapshot and public API support for new custom field types, published 2026-10-10. If you already turned the new field types on through Labs, HighLevel says you need no extra activation. The field types themselves were announced earlier, in the Introducing new custom fields entry of 2026-09-16.
What problem do these custom field types solve?
They give CRM data a proper home. Without typed fields, teams push dates, links and long notes into plain text fields or into the notes tab, where nothing can filter, sort or trigger a workflow from them.
Three problems are common in CRM accounts:
- Data stuck in notes. A technician writes the gate code, the preferred contact time and the referral link into one note. No report can find it later.
- Dates typed as text. "March 3rd", "3/3" and "next spring" in the same field cannot drive a renewal reminder or a "service due" list.
- Snapshots that lose fields. An agency builds a clean setup, copies it to a new sub-account, and then recreates fields by hand because they did not travel with the copy.
The third one is what this entry addresses. HighLevel says snapshot support eliminates the need to manually recreate field configurations across sub-accounts. The first two are problems typed fields help with; the changelog does not discuss them.
What is each new field type good for?
URL fields hold links, Date & Time fields hold real dates, Rich text fields hold formatted notes, Users fields point a record at team members, and image options make Radio and Checkbox choices easier to recognise. The descriptions below come from HighLevel's September 16 announcement.
| Field type | What HighLevel says it does | Example in a service business (ours) |
|---|---|---|
| URL | Captures web addresses in a structured field. You can allow all domains, allow only specific domains, or block specific domains. | A clinic stores the link to a referral form; an agency stores the client's website. |
| Date & Time | Date and time, date only, or time only. Can be limited to future dates, past dates or a date range. | HVAC: install date, last service date, warranty end date. Clinic: preferred contact time. |
| Rich text | Longer text with formatting such as bold, italics, headings and lists. | Clinic intake summary, or a job scope with bullet points for the crew. |
| Users field | Select one or several users on a record. HighLevel says users assigned this way also get follower-level access. | An agency stores the account owner and a backup owner on every client record. |
| Images in Radio and Checkbox | Add an image or icon beside individual options (icons are mentioned for Radio options). | A remodeler lets a lead pick finish styles by picture instead of by name. |
The examples in the right-hand column are ours. HighLevel's own examples include important dates, renewal dates, preferred contact times and scheduled events.
How do you design a clean custom field set?
Name every field with one pattern, keep one source of truth for each fact, and give each piece of data the type that matches it. Skip anything you will never filter on, report on or use in a message.
- Name with a pattern. Pick one style, such as "Object - Detail": "Equipment - Install Date", "Equipment - Warranty End". Avoid "Date 2" and "Notes new".
- One fact, one field. If the account owner lives in a Users field, do not also keep a text field called "Account manager". Two copies drift apart within weeks.
- Match the type to the question. If you will ask "who is due for service in 30 days", the field must be a date. If a person will only read it once, a Rich text field is enough.
- Keep machine-read data in typed fields. Anything a workflow or report must read belongs in a typed field, and the formatted paragraph stays for people.
- Decide what to leave out. Skip data you have no reason to keep, and keep sensitive health, payment or ID details out of general custom fields. For regulated data, check your own compliance rules first; the HighLevel entry says nothing about this.
- Keep a field list. One sheet with field name, type, purpose and owner. It is the first thing a new team member or a custom CRM build will need.
If your account structure is already tangled, fix the source before you copy it. Our GoHighLevel CRM setup starts with field and pipeline design, and an account cleanup handles old records.
What changes for agencies that ship snapshots?
Agencies can now include the new field types in a snapshot and deploy them to sub-accounts instead of recreating them by hand. That keeps client accounts on the same field set and cuts setup time.
A safe rollout looks like this:
- Add the new fields to the source sub-account and fill a few test records.
- Create or refresh the snapshot so it includes them.
- Push it to a blank test sub-account and check that each field arrived with the right type and options.
- Only then push to client accounts or attach it to a SaaS plan.
Two things the entry does not say, so test them: what happens when a destination account already has a field with the same name, and whether field values on existing records travel (HighLevel's wording is about field configurations). Our earlier note on Company and Custom Object Smart Lists in snapshots covers the list side: a Smart List that filters on a field only works where that field exists.
What changes for developers using the HighLevel public API?
HighLevel says it extended the public API to support all the new custom field types, so developers can work with them programmatically. The entry links to the Locations "Create custom field" page in the Marketplace docs.
HighLevel names these uses: building integrations, synchronizing custom field data with external applications, and automating processes without manual updates. For a scripted setup, create the fields through the API, then read them back to confirm the types. The request details for each type are in the linked Create Custom Field documentation. The changelog does not list them, so check the docs before you write code. For authentication and a working private integration, see our API v2 private integration guide, or our GoHighLevel API integration service if you want it built.
What happens to existing text fields that hold dates or links?
The HighLevel entry says nothing about converting old text fields to the new types, so assume there is no automatic migration. Plan to create new typed fields and move the data yourself.
A cautious path: create the typed field next to the old one, export a sample of records, clean the values (for example, turn "3/3" into a real date), import them into the new field, and switch workflows and reports over before you retire the old field. Keep the old field until a full report matches.
How do you audit your existing custom fields?
List every field, mark what is used, and flag text fields that really hold dates, links, owners or long notes. Those are the candidates for the new types.
- List all custom fields with their type.
- Mark fields used in no workflow, report, form or Smart List. Candidates for removal.
- Find text fields holding dates (renewal, install, last visit). Candidates for Date & Time.
- Find text fields holding links. Candidates for URL.
- Find text fields holding a staff name. Candidates for a Users field.
- Find duplicate fields for the same fact and pick one.
- Check the snapshot you ship: does it include the fields your lists and workflows depend on?
- Write the final field list down with name, type and purpose.
If you want a second pair of eyes, a field audit is part of our GoHighLevel CRM work.
Frequently asked questions
Do GoHighLevel snapshots include the new custom field types?
Yes. According to HighLevel's October 10, 2026 changelog entry, snapshots now support URL, Date & Time, Rich text and Users fields, plus images in Radio and Checkbox fields. The entry says this removes the need to recreate field configurations by hand in each sub-account, and that it is live for all accounts.
Can the GoHighLevel API create the new custom field types?
HighLevel says the public API now supports all the new custom field types, and the entry links to the Locations "Create custom field" documentation. The entry does not list request parameters for each type, so read that documentation and test in a sandbox sub-account before building anything on it.
Do I need to turn on Labs to use the new custom fields?
The entry says that if you already enabled the new field types through Labs, you need no extra activation for the snapshot and API support. It also says the support is live for all accounts. It does not describe a Labs step for anyone who has not enabled the types, so check your own account settings.
Will my old text fields turn into date or URL fields?
The HighLevel entry does not mention converting existing fields, so there is no confirmed automatic migration. Create new typed fields, clean and move the values yourself, and keep the old field until your reports match. Test on a copy of the data first.
Sources
- HighLevel changelog, Introducing snapshot and public API support for new custom field types, published 2026-10-10, checked 2026-10-14.
- HighLevel changelog, Introducing new custom fields, published 2026-09-16, checked 2026-10-14.
- HighLevel Marketplace docs, Create Custom Field, linked from the changelog entry; link only, page not read, checked 2026-10-14.
