Custom fields and the Properties studio

Every business has something the standard fields do not cover — a licence number, a renewal date, a account tier. Custom fields are how you add those without waiting on anyone.

The main decision is not which type to use. It is whether the field should exist at all.

Who this is for

Admins shaping the data model.

Before you start

• Permission to manage custom fields.
• A clear answer to what the field is for and who will fill it in.

Pick the type, not just text
A date stored as text cannot be filtered by range, and a dropdown stored as text collects seven spellings of the same value. Choosing the right type is what makes a field usable in filters, reports and automations later — text is the type that quietly costs you the most.

Add a field

1. Choose the record it belongs to
   Contacts, companies, deals, or a custom object you have created. Put the field where the fact actually lives — a renewal date belongs on the thing being renewed.
2. Pick the field type
   Text, number, currency, date, checkbox, email, phone, URL, dropdown or multi-select. Each comes with the right input and validation built in.
3. Use a dropdown for anything with fixed options
   If there is a known set of answers, make it a dropdown. This is the single biggest difference between data you can report on and data you cannot.
4. Set the rules
   Decide whether it is required and what a valid value looks like. Required fields are worth using sparingly — an unfillable required field blocks work.
5. Publish it
   The field becomes available on records once published.
6. Review what is actually being filled in
   A field that is always empty is costing everyone a moment and giving you nothing. Remove it.

What you get

• A data model that fits your business rather than a generic one.
• Fields with proper types, so they work in filters, reports and automations.
• Validation at entry, which is far cheaper than cleanup later.
• No engineering dependency to add a field.

Frequently asked questions

What field types are available?

Text, number, currency, date, checkbox, email, phone, URL, dropdown and multi-select — each with the right input and validation for its type.

When should I use a custom object instead of a custom field?

A field describes the record it sits on. A custom object is for a thing with its own life and its own records — if you would want a list of them, it is an object, not a field.

Should I make fields required?

Rarely. A required field someone genuinely cannot answer stops them working. Require only what you truly cannot proceed without.

Can I change a field's type later?

Treat the type as a decision to get right up front — converting between types is where existing data gets lost or mangled. Think about how you will filter and report on it before you choose.