Docs / Operations
Custom fields
The two or three things about your business OrderDen does not know — added properly, so they filter, export, import and print rather than living in a notes box.
Every business has two or three things OrderDen does not know about: a wholesale account number, a scent family, the gate code for a site, the contract reference the customer's own system generated.
The alternative to a field for them is the notes box — and a notes box is where information goes to stop being reportable. You cannot filter it, export it as a column, or print it on a document.
Company Settings → Custom fields adds them properly. A field you define there appears on the form, in the list's column picker, in the filters, in the CSV import and export, and in the API — all of it, without asking you again.
Adding one
Fields are per record: clients, items, orders, quotes, invoices, vendors, purchases, projects and expenses each have their own list. For each field you set:
- Label — what people see. Changeable whenever you like.
- Key — what the value is stored under, and what the API and the CSV column use. Letters, numbers and underscores. Fixed once created: every value is stored under it, so renaming it would orphan them all. Rename the label instead.
- Type — text, number, date, yes/no, a link, choose one, or choose several. The pickers need their choices listed.
- Required from now on — enforced the next time each record is saved. It does not go back and invalidate records saved before the field existed.
- Offer it as a list column — it joins that list's column picker.
- Print it in the document header — quotes, orders and invoices only, beside Issued and Customer PO. Nothing else has a document to print into.
Drag (or use the arrows) to set the order they appear on the form.
Filling them in
They appear on the record's own form, under Your own fields. Types behave the way you would expect: a date field takes a date, a number field takes a number and says so if it does not, and a picker only takes its own choices — typed in any case, stored as you spelled it in the settings.
Filtering by them
Lists take them as cf.<key> in the address bar, which means a saved
view remembers them like any other filter:
?cf.account_no=4471 |
Exactly that |
?cf.notes=contains:gate |
Text search |
?cf.scent_family=Citrus,Woody |
Any of those |
?cf.visit=after:2026-01-01 |
Dates, with before: too |
?cf.reorder=true |
Yes/no |
Type into a text field with no operator and it searches; type into a picker and it matches exactly. A filter naming a field you have since deleted is quietly ignored rather than breaking the saved view it lives in.
Import and export
CSV export includes every custom field as its own column, headed with the field's label. CSV import offers them in the mapping step like any other target, so a sheet whose header already says "Wholesale account no." maps itself. Blank cells are skipped rather than written as empty — a spreadsheet is mostly blank cells, and "not in this file" is not the same as "clear it".
Deleting a field
Removing a definition stops its values being shown, exported or filterable straight away. The values themselves stay on their records until something writes to that record's custom fields again — so if you delete a field by mistake, add it back with the same key and everything is where it was. That is an undo rather than a shredder, which is the right way round for data somebody typed.
In the API
Every one of the nine entities accepts and returns customFields as an
object keyed by your keys, and every list endpoint takes the same
cf.<key> filters. A partial write merges — sending one field never clears
the others — and an explicit empty clears one. The definitions themselves are
at /api/v1/custom-fields. See the API reference.
Everything on this page is in the free tier — one person, the whole product, no card.
Start free