A field is information about a person that carries a value: their city, an order number, an appointment date, how many times they typed the wrong code. A tag says "yes or no"; a field says "what the value is". Whatever your flows collect and whatever arrives from outside systems is stored in fields on the contact card.
💡 A field belongs to the account and is not defined in advance: it exists the moment a flow writes to it for the first time.
What a field is for
A field does three jobs at once:
- It stores information. The customer tells you once and you never ask again.
- It feeds decisions. Conditions read the value and split the flow.
- It personalises messages. A placeholder prints it inside the text.
Built-in fields and custom fields
There are two kinds:
- Built-in fields — Name, E-mail and Phone. These are the contact card's own fields and appear under the same name everywhere in the panel.
- Custom fields — The ones you create: city, order_no, appointment_date, attempt_count… You choose the name.
When a step or a rule asks for a field, the list offers the three built-ins first and then a Custom field option; pick it and type the name.
How a field is named
A custom field name follows this rule: it starts with a lowercase letter, contains only lowercase letters, digits and underscores, and is at most 40 characters long. The hint on screen says the same.
Valid: city, order_no, appointment_date, attempt2.
Invalid: City (capital letter), order no (space), 2attempt (starts with a digit).
⚠️ Note: the field name and the label shown on screen are the same thing; there is no separate "display name". Choose clear, consistent names, and agree on a convention with your team: always singular, always plain ASCII, always underscored.
How a field is filled
There are six ways:
- Collect information step — Asks the question, validates the answer against a format and writes it to the field. The formats are text, e-mail, phone, number, date and address. A wrong format is asked again; when the retries run out, the flow continues from the step's Invalid answer output. With Do not ask if the field is already filled enabled, someone who already answered is not asked twice.
- Set field action — Writes a fixed value or text containing placeholders.
- Increase/decrease field action — Raises or lowers the number in the field. A value that cannot be read as a number counts as 0.
- Clear field action — Empties the field.
- A message step's reply — If a message step is waiting for a written reply, you can save that reply straight into a field.
- External request step — Maps values from another system's response into fields; one step can carry up to 10 mappings.
In addition, the AI step in chat mode asks for the information you listed itself and writes what it learns to the contact card.
How a field's value is stored
Fields hold their value as text; there is no separate "number field" or "date field" definition. The format is the job of the step that fills the field:
- The Collect information step validates the format (e-mail, phone, number, date, address) and writes only an answer that fits.
- A condition doing a numeric comparison (greater than, less than) tries to read the value as a number; if it cannot, the rule is not met.
- The scheduled trigger, when reading a date field, also asks for a send hour for dates written without a time.
The practical consequence: pay attention to which step fills a field. A hand-typed "tomorrow" is not a date and the scheduled trigger cannot use it.
Where you use a field
- In a condition. The Field rule works with equals, not equals, contains, does not contain, empty, not empty, greater than and less than. Asking "is it empty" is the basis of every flow that fills in what is missing.
- In message text. You write it as a placeholder and it is replaced by the value at send time. See Variables and placeholders.
- In a scheduled trigger. The Date and time trigger can run off a date field: 24 hours before an appointment, or the same day every year.
- In a general rule. The Field changed event starts a rule; type a field name into the filter box to limit it to that field.
- In an external request. As a placeholder in the path or the body of the address, for example "/order/{{field.order_no}}".
A concrete example
A parcel-tracking flow is built like this:
- A Collect information step asks "What is your order number?", leaves the format as text and writes the answer to the
order_no field.
- An External request step calls the shop's system at
/order/{{field.order_no}} and maps the status from the response into the delivery_status field.
- A Condition step looks at
delivery_status: one branch if it contains "delivered", the other if it does not.
- A Message step writes "Your order is {{field.delivery_status}}."
- When a wrong number is entered, an Increase/decrease field action raises
attempt_count by 1, and after three attempts the flow hands over to a human.
Suggestions for naming fields
Field names are hard to change once they settle in, so choosing well from the start saves work:
- Use the singular:
order_no, not order_numbers.
- Stick to plain ASCII:
city, not şehir.
- Pick one name per concept: do not create both
tel and phone_no.
- Make date fields obvious:
appointment_date, birth_date. You save time when picking one in a scheduled trigger.
- Make counter fields obvious:
attempt_count, points. The name should already say that Increase/decrease field belongs there.
- Do not create throwaway fields. A field you opened for one flow's intermediate value stays on the contact card for good.
Common mistakes
- Using spaces or non-ASCII letters in a field name. They are not accepted; write
city, not City or şehir.
- Keeping the same information under two names.
phone and tel_no are two different fields, and your filters split in two.
- Skipping the format on a Collect information step. If you expect a phone number, set the format to phone; otherwise "I'll call tomorrow" is saved as a phone number.
- Turning off "Do not ask if the field is already filled". With it off, you ask the customer for something you already know.
- Using Set field to keep a count. Counting needs Increase/decrease field.
- Misspelling the field name in a placeholder. An unrecognised placeholder stays empty and the message goes out with a gap in it.
Keep your fields tidy and your flows will never ask the same question twice, and every message will go out with the right information in it.