Custom fields
Overview
Custom fields are your own fields, attached to existing kinds of data — without anybody having to program. They then appear on that data's detail page and are treated like the shipped fields.
They are possible on: customer · contact · lead · deal · ticket · project · task.
The reason this surface exists is simple: every organisation keeps one or two details no standard product can anticipate. Such details belong in a field, not in a notes box — only then can they be filtered, reported on and automated.
Core tasks
Create a field. New field requires a label, a technical key, the entity and the field type. The key is the name by which the field is addressed in the API, in templates and in automations — lowercase, no spaces, industry for example.
Make it required. A required field has to be filled on save. Set that only once the existing records are cleaned up — otherwise the new field blocks editing of old ones.
Deactivate a field. The active toggle hides a field without discarding the values already captured. That is the gentle route when a field is no longer needed.
Make built-in fields required. Below the field list are the required standard fields: for customer, contact, lead and deal a row of chips with the built-in fields that can become required — such as VAT ID, industry, owner or visiting address on the customer, email on the contact, company on the lead, expected close on the deal. One click makes the field required, a second one takes it back. Which fields are offered is decided by the record type itself. Effect: creating and editing without that field is refused, the form marks the field with an asterisk and names the error at the field. This applies to forms, the interface and AI tools. Import, lead conversion and automations do not check these rules — they keep creating records without this check, so that a missing detail stops no mail intake and no migration.
Fields in detail
A custom field extends a mask without changing code. The field appears in the interface, in the API, in filters and in reports — it is a real field, not a sticky note.
| Field | Required | Values / format | What it does |
|---|---|---|---|
Record type entityType | yes | customer, article, task … (max. 100 characters) | Which kind of record the field appears on. Not sensibly changeable later — the values recorded would then hang on the wrong type. |
Key key | yes | text, max. 100 characters | The technical identifier the API, imports and automation address the field by. Do not change it once values are recorded. |
Label label | no | text, max. 255 characters | What appears in the mask. Freely changeable. |
Type type | yes | text, number, date, choice, yes/no, reference … | What can be entered. It determines the input control and how the field behaves in filters. |
Options options | with "choice" | list of values | What is on offer. |
Target record type refTargetEntity | with "reference" | record type, max. 100 characters | What is referenced — creating a real link instead of a retyped number. |
Required required | no | yes/no | Whether saving without a value is possible. Consider the existing data: a new required field makes every existing record incomplete. |
Requirement rules requirementRules | no | conditions | Required only under conditions — say only for business customers. The gentle route instead of a hard requirement for everyone. |
Formula formula | no | text, max. 2000 characters | A calculated value instead of an entry. The field is then determined, not filled in. |
Materialised materialized | no | yes/no | Whether the calculated value is stored. On makes it sortable and filterable but costs refresh effort; off recalculates on every read. For a field you sort lists by there is no way past on. |
Brand brandScope | no | one of your brands | Which brand the field applies to. |
Pipelines pipelineIds | no | list of pipelines | Which pipelines the field is limited to. Empty = it applies to all of them. That keeps a form lean: a field only direct sales needs never shows up in partner business. |
Extra read permission readPermission | no | permission name, max. 100 characters | A second hurdle in front of this one field, a margin figure not everyone should see for instance. Whoever lacks the permission neither sees nor can write the value, even when allowed to edit the record otherwise. Empty = no extra hurdle. |
Order sortOrder | no | number | Position in the mask. |
Active active | no | yes/no | Off hides the field without deleting the values. The right route for a field no longer needed — deleting would take the recorded entries with it. |
Required standard fields
| Field | Required | Values / format | What it does |
|---|---|---|---|
Record type entityType | yes | customer, contact, lead, deal | Which record type the rule applies to. Leads and deals only while the CRM module is active. |
Field fieldName | yes | an offered standard field (list in the meta catalogue standardFields) | Which built-in field becomes required. Fields the record type does not offer are rejected — there is no rule nobody enforces. |
Rule requirementRules | yes | {"save": "required"} | The same shape as the requirement rules of custom fields: context save = on every save, level required = no save without a value. One rule per record type and field. |
Settings & permissions
- Maintaining required fields needs the
platform.settings.managepermission; any signed-in user
may read them — the forms mark their required fields with them.
- No route permission of its own. The page is reachable; whether you may create and change
fields is checked by the server on save.
- The key is permanent. It is used in places that cannot all be carried along. Choose it with
care.
- Fields apply across brands. A custom field on the customer applies to every brand — customers
are brand-neutral master data.
- The fields are available everywhere. What is created here is also available over the API, in
automations and to the AI assistant — not only in the interface.
FAQ & troubleshooting
The new field does not appear on the detail page. Check the chosen entity and the active state. A field on contact does not appear on the customer — those are two kinds of data, see Contacts.
Old records suddenly cannot be saved. Then a new required field is the cause. Withdraw the requirement, clean up the records, then set it again.
Since a new required-field rule a customer can no longer be saved. An existing record without the field needs it on every save from now on. Fill in the value or take the rule back (deselect the chip).
I want to delete a field. Deactivate it. Deleting would take the captured values with it.
When a tag rather than a field? A field carries one value per record; a tag is free multiple labelling — see Tags.