Custom fields
Custom fields let you adapt the CRM to your company's vocabulary without changing the product: "contracted plan", "unit number", "lead source".
They exist for two entities:
- Contacts — values per person;
- Campaigns — values per send (see Campaigns).
Create a field
- Open Settings → Custom fields.
- Choose the entity (contacts or campaigns).
- Click New field and define:
| Property | What it does |
|---|---|
| Label | How the field appears on the screen (and in the views) |
| Type | Text, number, date, selection, boolean, among others |
| Options | For selection fields, the list of accepted values |
| Required | Prevents saving the record without the value |
| Searchable | Includes the field in search and filters |
- Save. The field appears immediately on the records and can now be used as a column and filter in the views and as a column in the reports.
Validation
The value is validated by the field's type before being saved — in the interface, in the CSV import, in the API, and in MCP. An invalid value is rejected with the list of fields with problems (custom_field_validation), never saved partially.
How the count works
On the editing screens, a custom field counts as one change per key: changing two custom fields shows "2 unsaved changes". That number is the same one the Save button applies at once.
Delete a field
Deletion removes the field from the screens, the views, and the reports. The values saved in the records are not recoverable through the interface — if the data matters, export a report with the column before deleting.
Use labels that don't change meaning. Renaming a field is cheap, but saved reports and views that use it start showing the new name — the history doesn't keep the old label.
Fields of system entities
In addition to custom fields, each company can rename the entity labels (for example, calling "Contacts" "Customers") in Settings → Entity names. The label changes throughout the product, including in the screens generated by views.