Custom fields are where the part of your CRM that is actually yours lives. Anyone can rebuild a GoHighLevel pipeline in an afternoon. Nobody can rebuild the lead source, budget range, property type, and qualification score that two years of forms and workflows wrote into thousands of contact records.
The direct answer for anyone who landed here because a field just disappeared: HighLevel has no restore for custom fields. Deleting one permanently removes the field and every value stored in it, across all records, and the platform documents that in plain language. Contacts get 60 days. Opportunities get 60 days. Pipelines can be revived from Audit Logs. Custom fields get nothing.
That is a strange asymmetry once you notice it, because the blast radius of deleting a custom field is much wider than deleting a single record. One click in Settings reaches into every contact in the sub-account at once.
What happens when you delete a HighLevel custom field?
It is permanent, and it takes the data with it. HighLevel’s documentation on opportunity custom fields answers the question in its own FAQ: deleting a custom field permanently removes the field and any data stored in it from all opportunities, and the action cannot be undone. The forms and surveys guide repeats the warning for contact fields, telling you that deleting a field from Settings removes it from all forms, surveys, and contacts where it was used.
HighLevel’s own suggested alternative is telling. Rather than offering an undo, the docs recommend that if you only want the field out of sight, you move it into a folder or use the Hide Empty Fields option instead of deleting. That is good advice. It is also an admission that delete is a one-way door.
Two things make this easier to trip over than it should be. The Custom Fields page supports bulk actions, so you can select several fields with checkboxes and delete them in one go, which turns a single misjudgement into several columns of lost history. And fields commonly get tidied by whoever is cleaning up the account rather than by whoever built the forms, which means the person pressing delete is often not the person who knows what was feeding that field.
Can you restore a deleted custom field?
Not through any documented path. This is worth spelling out because HighLevel has spent the last couple of years filling in restore paths almost everywhere else. Deleted contacts can be recovered for 60 days, and since the October 2025 update the restore brings back associated data unless that data was deleted separately. Opportunities have the same 60-day window. Deleted pipelines, along with their stages and opportunities, can be restored from Audit Logs. Bulk deletes of custom objects, companies, and tasks can be undone from the Bulk Actions page.
Custom fields sit outside all of it. There is an open request on HighLevel’s ideas board asking for custom fields to be covered properly in Audit Logs, with a few hundred votes behind it and a status of in progress. It was filed in 2022. Several comments on that thread are from agency owners pointing out that even the existing custom field entries in Audit Logs are hard to read, listing fields by ID rather than name. So the feature may well land eventually. It has not landed yet, and you should not plan around it.
Do HighLevel snapshots back up custom fields?
They back up the structure. Snapshots copy Custom Fields, Custom Objects, Custom Values, Pipelines, Tags, and Trigger Links as part of the CRM and Data Structure category, so loading a snapshot into a fresh sub-account does rebuild your field architecture: names, types, dropdown options, the lot. For onboarding a new client on a proven setup, that is exactly right.
What a snapshot does not carry is a single contact, and the values live on the contacts. HighLevel’s snapshot overview lists contacts, appointments, conversations, messages, and live account activity among the items that do not transfer, and its FAQ answers the question directly. So a snapshot restores the empty shape of your data. Every cell in it is blank.
This is the same boundary we covered in snapshots versus backup, and it bites harder here than almost anywhere else, because with a funnel or a workflow the configuration genuinely is the asset. With a custom field, the configuration is the cheap half.
Does the contact export include custom field values?
Yes, but only for fields you remembered to display first. The CSV contains the columns currently visible in the contacts table, so a custom field that is not shown as a column simply will not appear in the file. Click Manage Fields and tick everything before you run the export. We went through the full process in how to export HighLevel contacts, and this is the single step where most incomplete exports happen.
Even done carefully, the export has the weaknesses any CSV has. It is per sub-account, so a ten-client agency runs it ten times. There is no scheduling, so somebody has to remember. The download link expires after 30 days. And it captures contact fields only, so opportunity custom fields are not in that file at all.
Here is how the native options actually line up:
| Native option | What it protects | What it misses |
|---|---|---|
| Snapshot | Field definitions, types, dropdown options, custom values | Every value stored on a contact or opportunity |
| Contact CSV export | Values in the fields you displayed as columns | Undisplayed fields, opportunity fields, and anything changed since |
| Audit Logs | A record that a change happened | No restore action for custom fields |
| Folders and Hide Empty Fields | Clutter, not data | Nothing, but it is the safe alternative to deleting |
Read across that table and the pattern is the one this blog keeps running into. HighLevel protects configuration well and protects the data inside the configuration poorly.
Can you back up custom fields through the API?
Yes, and this is one of the more straightforward objects to pull. API v2 exposes GET /locations/:locationId/customFields with a model query parameter that accepts contact, opportunity, or all, and it returns the field id, name, field key, data type, position, and picklist options for each one. There are matching endpoints to read a single field, create, update, and delete, plus a file upload endpoint for file-type custom fields. Custom values have their own set at the same level, with get, create, update, and delete.
That gives you the definitions. For the values, you are back in the contacts and opportunities endpoints, pulling records and reading the custom field array on each one, which is the same sweep you would already be running if you are backing up contacts at all. The usual API v2 limits apply: 100 requests per 10 seconds and 200,000 per day per app per location.
So a DIY backup job can cover this, and if you have already built one for contacts then custom field definitions are a cheap addition. The warning is the same as it always is. Pulling data out is the easy half. Restoring means recreating fields through the API, in the right order, with matching field keys so that existing references in forms and workflows resolve again, then writing values back onto records without clobbering anything that changed in the meantime. That is a real project, and you will be attempting it on your worst day.
What about custom values?
Custom values are the other half of this problem and they get discussed far less. They live under Settings, then Custom Values, and they hold the reusable strings your whole account leans on: the client’s business address, the support phone number, booking links, offer names, brand colors in email builder inputs. Workflows, funnels, emails, SMS, and social posts all reference them rather than storing copies.
That reference model is what makes them quietly dangerous. Delete a custom value and nothing errors. The merge tag just resolves to nothing, so the email goes out with a blank where the phone number should be and the funnel page renders an empty headline. HighLevel’s newer workflow builder helps a little here by color-coding dynamic value chips, with red meaning the value does not exist in HighLevel at all, but that check lives in the workflow builder and does not follow the value into every funnel page and email template that used it.
The documented options for managing custom values are create, edit, and delete via the three dots next to each entry. No restore is described. Snapshots do carry them, so a snapshot refreshed recently is genuinely useful for custom values in a way it is not for contact field data, which is worth knowing if you only take one thing from this post.
How do you actually back up custom fields?
Manually, there are three habits worth building, and none of them take long. Run the contact CSV export with every custom field displayed as a column, on a cadence you will actually keep, and store the files outside HighLevel. Refresh your snapshots after you change field structure, since the snapshot is your only native copy of the definitions and it does not update itself. And treat the Custom Fields page the way you would treat a production database: nobody deletes a field without first checking which forms, workflows, and smart lists reference it, because there is no undo waiting if they guessed wrong.
The automated version is why we built GHLArmor, and since it is our product you should weigh the recommendation accordingly. GHLArmor is the first backup approved by the HighLevel Marketplace. It captures custom fields and their values continuously alongside contacts, opportunities, tasks, notes, and conversations, keeps version history, and stores all of it outside HighLevel, so a restore does not depend on an Audit Log entry that was never written.
The honest framing is the one we would give about any part of this platform. Use the native features, because they are free and they cover the common cases well. Just be precise about where they stop. For custom fields, they stop at the definition, and everything your clients care about is on the other side of that line.
Frequently asked questions
What happens when you delete a custom field in HighLevel? The field and every value stored in it are permanently removed from all records, and the action cannot be undone. HighLevel states this directly in its documentation for opportunity custom fields, and the forms and surveys guide carries the same warning: deleting a field from Settings removes it from all forms, surveys, and contacts where it was used. There is no trash, no recently deleted list, and no restore path.
Can you restore a deleted HighLevel custom field? No documented path exists. Contacts have a 60-day restore, opportunities have one, and deleted pipelines can be revived from Audit Logs. Custom fields were left out of that pattern. An open feature request asking for custom field coverage in Audit Logs has been marked in progress since 2022, which tells you the gap is known and still open.
Do HighLevel snapshots include custom fields? They include the field definitions, not the data. Custom Fields, Custom Objects, and Custom Values all appear in the CRM and Data Structure category of assets a snapshot can copy, so loading one rebuilds your field structure in a fresh sub-account. Contacts do not transfer, and the values your contacts have stored in those fields go with them.
Does the HighLevel contact export include custom field values? Only for the fields you made visible as columns before exporting. The CSV contains the columns currently shown in the contacts table, so if a custom field is not displayed, it is not in the file. Click Manage Fields and tick everything you want before running the export, because this is where most incomplete exports happen.
Are custom values backed up anywhere in HighLevel? Snapshots copy them as configuration, and API v2 exposes read endpoints for them at the sub-account level. Inside the app, the documented options are create, edit, and delete, with no restore. Since custom values feed funnels, emails, and workflow messages by reference, deleting one does not break loudly. It just renders blank wherever it was used.