Custom contact fields and lists you can tidy without losing data
Give every custom field a type, a permanent key and a label you can rename, store dates as YYYY-MM-DD, and make sure deleting a field or a list can never delete the values underneath it. In Email Digit a field’s key is fixed once it is created, its label is not, and deleting a field or a list removes only the definition or the membership. The contacts and their stored values stay.
Why custom fields get messy
Custom fields are where a contact list starts to look like your business: a renewal date, a membership tier, a branch, a number of seats. They are also where lists decay. Someone adds Spring offer for one campaign, someone else adds spring_offer_2 because they could not find the first, and a year later nobody knows which one the welcome automation reads.
The tidy-up is where data gets lost. When the field definition and the stored values are treated as the same thing, removing a field you think is unused removes every value in it, including the ones an automation still depends on.
Rules that keep fields tidy anywhere
- Pick the type for how the value is used. If you will start something on it, it is a date. If you will count or compare it, it is a number. If there are only a few right answers, it is a select, so “Gold”, “gold” and “GOLD” cannot become three tiers.
- Separate the name people read from the name systems read. The label can change with your wording. The key that imports and automations refer to should not.
- Write dates one way.
2026-03-14sorts, compares and parses everywhere. “14/03/26” means different things in different countries. - Do not use fields for one-off campaigns. Who got the spring offer is a list or a tag. A field is for something that stays true about the person.
How fields work in Email Digit
Every field has four parts:
| Part | What it is | Can it change? |
|---|---|---|
| Label | What people see on the contact’s Profile tab and in the import mapper | Yes, any time |
| Key | Where the value is filed on each contact. Made from the label when you create the field, so “Renewal date” becomes renewal_date | No |
| Type | Text, select, date or number | Yes; stored values are left as they are |
| Options | The fixed choices, for select fields only | Yes |
The key cannot be renamed because every stored value is filed under it. Renaming it would leave each value pointing at a field that no longer exists. Two fields cannot share a key in the same workspace, so you cannot create a quiet duplicate by accident.
Changing a field’s type changes the input, not the data. A value saved as text stays as it was written; switching the field to a date does not convert “next March” into one.
Where fields get used
- Imports. When you import a CSV, each column can be mapped to one of your fields.
- Automations that start on a date. The “On a date” trigger reads a date field, such as a renewal or a birthday, and can run once or every year. It reads the value as
YYYY-MM-DDand skips any contact whose value it cannot read as a date, which is the practical reason to store dates that way. A 29 February birthday fires on 28 February in other years. - Waiting and writing. A flow can wait until the date in a field, and a “Set a field” step can write a value, for example marking that someone finished onboarding.
Deleting without losing data
Deleting a field removes the definition, not the data. The field disappears from every Profile and from the import mapper. The values already stored on contacts stay in their data, and if you create a field again with the same key, they show again.
Deleting a list removes the list and its memberships. The contacts stay, along with their other lists, tags, fields and history. The confirmation dialog says so before you click.
So retiring last year’s spring_offer field or the 2025 open day list is a cleanup, not a data loss. A change to the shape of your list should never be able to destroy a value.
Limits
- Custom fields are not merge fields yet. The merge fields the editor offers are first name, full name, email and the unsubscribe link. A custom field cannot be dropped into the text of an email today.
- The contacts CSV export does not include custom fields. Keep your own source file if you need those values outside Email Digit.
- Values of a deleted field are kept but not shown. They are invisible in the dashboard until a field with the same key exists again.
- Changing fields needs the Editor role or higher. Viewers can see fields but not change them.
See what Email Digit does for marketers, or start a 14-day trial and set up your first fields.