Create and manage custom fields

Custom fields are created and managed from one place in your account, whether you'll eventually use them on a form, in a workflow, or nowhere but the contact record itself. This article walks through creating a field, naming it well, organizing it with folders, and the two operations that need extra care: editing and deleting.

#Creating a custom field

1. Go to Settings > Custom Fields.
2. Use the object selector at the top of the page to choose which record type the field belongs to — Contact or Opportunity (or another custom object if your account has them). Stay on the Fields tab.
3. Click Create field in the top right.
4. Enter a field name. This is what your team sees everywhere the field appears — the contact record, the form builder's field picker, the merge tag list. Make it specific enough that nobody has to guess what it means six months from now.
5. Choose a field type (short text, number, date picker, dropdown, checkbox group, and so on — see Custom fields overview for the full list). For dropdown, radio, or checkbox fields, add each option now; you can add more later, but removing an option that's already in use on live records takes extra care (see below).
6. Optionally assign the field to a folder so it's grouped sensibly on the record layout and in field pickers.
7. Save the field.

The field is now live across the account immediately — it will appear on the relevant record layout, in the "add field" list for forms and surveys, in the merge tag / variable picker for emails and SMS, and as a filter option in smart lists.

Tip: Before creating a new field, search the existing list first. It's easy to end up with "Budget," "Budget Range," and "Client Budget" as three separate fields that each hold part of your data. Reuse beats a fresh field almost every time.

#Naming and keys

The field name is what your team sees; behind the scenes, the platform also generates a unique key for the field so it can be referenced consistently in merge tags and integrations. You generally don't need to think about the key day to day — the platform handles it — but it's worth knowing it exists, because it's why renaming a field's display label later is safe (the underlying key, and therefore every workflow and merge tag pointing at it, doesn't break), while changing which object a field belongs to is not possible at all once created.

#Organizing fields with folders

If you're managing more than a handful of fields, create folders before your field list gets unwieldy rather than after:

1. From Settings > Custom Fields, switch to the Folders tab.
2. Click Create folder, name it (e.g. "Buyer Information," "Sales Qualification"), and save.
3. Back on the Fields tab, assign existing or new fields to the folder — either from the field's own settings, or by dragging it into the folder in the list view, depending on your account's interface.

Folders appear as labeled sections on the record layout and as group headers when your team is choosing a field to add to a form. They're purely organizational: moving a field between folders never changes its data, its type, or anything referencing it elsewhere.

#Editing a field

You can rename a field, change its folder, or add options to a dropdown/checkbox/radio field at any time without affecting existing data. Two edits deserve more caution:

• Removing an option from a dropdown, radio, or checkbox field. Any record that already has that option selected keeps the stored value, but the option will no longer appear as a choice going forward, and reports or filters built around it may need review. Confirm nothing downstream (a workflow condition, a smart list filter) depends on the exact option text before removing it.
• Changing a field's type. Not every type change is offered, and converting a field with existing data (say, from free text to a dropdown) can strand answers that don't match any of the new options. If you need a materially different field, it's often cleaner to create a new one and migrate the data deliberately than to force an existing field into a new shape.

#Deleting a field

Deleting a custom field is permanent and removes the stored value for that field from every record it exists on — there's no per-record undo. Before deleting:

1. Check whether the field is referenced by any active workflow (as a trigger condition, an if/else branch, or an update-field action). A deleted field referenced by a live automation can break that automation's logic.
2. Check whether it's mapped on any live form or survey. If it is, that question will stop saving anywhere once the field is gone.
3. Check whether it's used in any email or SMS template as a merge tag — the merge tag will render blank instead of failing loudly, which is easy to miss until a customer receives an email with an empty gap in it.

If you're confident nothing depends on it, delete it from Settings > Custom Fields, using the same Fields tab where it was created. If you're not confident, consider renaming it to something like "Archived — Old Budget Field" and removing it from any forms instead, so the historical data stays intact while the field stops being used going forward.

Warning: There's no built-in way to recover a deleted field's stored answers. If a field holds data you might need later — even data you're not actively using today — export it (via a smart list export, covered in the Contacts articles) before deleting the field itself.

#What "done" looks like

A well-managed custom field list has clear, specific names, sensible folders, and no field whose purpose your team has to guess at. Before you delete anything, you've checked forms, workflows, and templates for references. That habit is the difference between a quick cleanup and an afternoon spent figuring out why a workflow stopped branching correctly.

#Related articles

• Custom fields overview
• Use custom fields in forms, surveys, and the contact record
• Use custom fields in emails, SMS, and automations

#Frequently asked questions

#Can I bulk-create custom fields, or does each one need to be added manually?

The standard path is one field at a time through Settings > Custom Fields, which is worth it for the naming and type decisions each field deserves. If you're standing up a large number of fields at once (a migration, for example), check with your account admin about import options before hand-creating dozens.

#If I rename a field, do forms and workflows that use it break?

No. Renaming only changes the display label your team sees. The underlying reference every form, workflow, and merge tag uses to point at the field stays the same, so nothing breaks from a rename alone.

#Can a contact field and an opportunity field share the same name?

Yes — they're separate lists tied to separate objects, so name collisions between them don't cause conflicts. That said, using distinct names (e.g., "Contact Budget" vs. "Deal Budget") makes life easier for anyone building a form or workflow who has to pick the right one from a list.