Skip to main content
Custom fields hold the details DMLY has no box for — a membership number, a car registration, an allergy note, how someone heard about you. You define the list once for your Workspace, then values are filled in per contact, by you or by a Flow, a booking form or a CSV import. Two things to know before you build your list, because they change what custom fields are good for:
  • You can’t filter or segment on a custom field. Segments are built from pipeline stage, tags and how long since the contact was last active — nothing else. The contacts list has no custom-field filter either, so a custom field can’t be the audience for a Broadcast. If you need to target a group, use a tag. Flows are a different story: a Condition step can branch on a custom field, and a date field can trigger an automation — see Automations and templates.
  • The list you define is a reference list, not a rule. The editor on a contact is a free-form name-and-value box. It doesn’t offer your defined fields to pick from, doesn’t check the name you type against them, and doesn’t check the value against the type you chose.
Because the contact editor matches on the name you type, a typo makes a brand-new field on that one contact and nothing warns you. allergy and Allergy are two different fields. Agree on names with your team and type them the same way every time.

​
The five types

When you define a field you pick one of five types: text, number, email, phone or date. The type is a label for your own reference. Nothing checks what you type on the contact page against it — a date field will happily hold next tuesday, and a number field will hold about six. Choose the type to tell your team what belongs in the field, not to keep bad data out. One place a sloppy value does bite: a date field used by a Birthday / key date trigger is parsed as a date when the trigger runs. A value it can’t parse is skipped silently — the automation simply never fires for that contact, with no error to tell you why.

​
Define a field for your Workspace

1

Open the Custom fields tab

Go to Settings → Custom fields. Definitions live at the Workspace level and are shared across every channel — you don’t set them up again per WhatsApp number or per page.
2

Add the field

Give it a name and pick a type. Names are unique within a Workspace, so you can’t have two fields called company.
3

Or import a list

If you’re bringing a field list over from another system, you can import it from a CSV on the same tab, and download a sample file there to match the format.

​
Add a value to a contact

1

Open the contact

Go to Contacts and select View details on the person. Scroll to Custom fields. With nothing set yet it reads No custom fields yet. Add one below.
2

Add a row

Select Add field, then fill in Field name and Value. Type the field name exactly as you defined it in Settings → Custom fields.
3

Save

The section saves as a whole set, not row by row. A row with an empty Field name is discarded when you save.

​
Where values also come from

You are not the only thing that writes custom fields. All three of these match on the field name, which is why consistent naming matters. Flows. This is the biggest writer of custom fields, and the field name is one you type into the node yourself. The User Input step has a Save answer to dropdown with a Custom field… option; pick it and you type the field name underneath. The Sync Contact step (in the Store (Shopify / WooCommerce) group) has a Set custom fields list, and the AI Reply step has a Set custom fields tool you can switch on. Plenty of the ready-made templates already do this — the shopping and support ones write fields like shopping_interest, order_number and issue_summary. See Flow builder. Booking forms. Booking form questions come from a fixed list — you can turn each one on or off and change its label, but you can’t add your own question. Four of them save their answer onto the contact as a custom field: Preferred Name, Identification Number, Address and Referral Source, landing in preferred_name, identification_number, address and referral_source. So a contact who books online can arrive with those already filled in. Not every question works this way — Date of Birth and Gender write to the contact’s own birthday and gender, and the emergency contact and additional notes answers are kept on the booking rather than the contact. A booking only fills a custom field that’s currently empty, so it never overwrites a value you already have. CSV import. The contacts import file has a custom_fields column that takes a JSON object — the sample file uses {"company":"Acme"}. If the row matches someone you already have (by phone or email), custom fields are merged key by key and the values in your file win — a field already on the contact is overwritten with the imported value, and fields you don’t include are left alone. This is the opposite of how the import treats name, email and phone, which are only filled in when they’re blank. See Import contacts from a CSV. The contacts export includes the same custom_fields column as JSON, so an export and re-import round-trips your fields.

​
Automations and templates

You can’t build a segment or a Broadcast audience from a custom field, but a Flow can still read one:
  • Branch on it. A Condition step offers Custom field…, where you type the field name and test it with is, contains or has any value.
  • Trigger on it. The Birthday / key date trigger takes a Date field — either birthday or the name of a custom date field, such as anniversary — and fires on the day, or a set number of days before it.

​
Flow answers

Answers a contact gives in a Flow are shown in their own Flow answers section on the contact page, separate from Custom fields, listing each question, the answer the contact gave and the date. Only the last 50 answers are kept. The panel doesn’t tell you which field an answer was saved to. Every answer lands here regardless of whether the step saved it anywhere; if a User Input step did save it to a custom field, the value also appears under Custom fields.