Skip to main content
Version: 2026.8.1

Fields

Fields are the details an item carries. A part might have a name, a quantity, a location, and a photo. A machine might have a model, a firmware version, and a purchase date. Every module comes with sensible fields already, and you add your own whenever you want to track something more.

Custom fields​

You can add a field of whatever type fits what you're recording:

  • text, for names and notes
  • numbers, for counts, measurements, or prices
  • yes / no, for a simple flag
  • a choice from a list you define, like a status or a category
  • a date, for due dates, arrivals, or when something was bought
  • rich text, for long notes and descriptions, edited as Markdown with a formatting toolbar and shown formatted on the record
  • a URL, which can render as an image when a picture is the point (items also carry a built-in photo)
  • a person, which becomes a dropdown of everyone in the workspace, showing their name rather than an id, with Unassigned as a real option. Renaming someone updates it everywhere, and a person who has left still shows on the records they were on
  • a relation, which links a record to another record. Modules and bundles contribute these, and you can also create one yourself from Configuration then Fields

A text field can also show as a scannable QR of its value, for a code you own like a location tag, an asset tag, or a link.

A dropdown can carry a one-off note beside its value. Pick "eBay" from the list and note the specific seller next to it, and the record reads "eBay · detroitaxle". The value stays "eBay", so grouping, filters and saved views still gather every eBay purchase together however many sellers you have noted. It is for a detail worth keeping that does not deserve a permanent spot in your choices list.

A new field shows up in the item's form, and you can add it as a column, group a kanban by it, or filter on it in any view.

What a field means, not just what it is called​

A field named "Best before" and one named "Use by" are the same idea, and a field named "Acquired from", one named "Source" and one named "Bought from" are another. Saying so is what lets the rest of Cobblr work with fields you invented.

So a custom field can carry a role from a short standard list, the same list bundles use. Marking one lets Cobblr fill it in for you, match it against a field someone else made, and warn you before you end up with two fields for one thing.

You set it from the Meaning dropdown on the new-field form ("When it became yours", "What it cost", "When it expires", and so on). It is optional, and leaving it blank is fine for a field you only ever type into yourself. A field with no meaning attached is one nothing fills for you.

Four of those roles describe how something came to be yours: where you got it, when, what it cost you, and who sold it. Mark your fields with those and a receipt fills them in, whatever you happened to name them. The rest cover what kind of thing a record is, its packaging count, an identifier printed on the object, an expiry date, and who it is assigned to.

The full list is in Fields and field types.

Sets you can switch on​

Some fields are worth having on everything you own, and building them one at a time gets tedious. The Fields page carries a short list of sets you can switch on in one click.

  • The first is Provenance: Acquired from, Acquired on and Paid, added to every physical thing you track, including kinds you add later.
  • Each field already carries its meaning, which is why it is a switch and not something you build by hand. Scan a receipt and the date printed on it goes into Acquired on, the shop into Acquired from, and the price into Paid.
  • They are plain fields, so a receipt can put a shop name in Acquired from whatever that shop is called.
  • Turning a set off removes its fields. Anything already recorded stays on your items and comes back if you turn the set on again.

Computed fields​

Some fields you don't fill in. A computed field builds its own value from the other fields on the item, and keeps itself up to date.

Two common cases:

  • A name assembled from parts. A vehicle's display name can just be {{ year }} {{ make }} {{ model }}, instead of retyping "2022 Toyota Corolla" into a name field when those three are already filled in.
  • A summary pulled from related records, like when something was last serviced, what's due next, or how much you've spent on it.

Computed fields are read-only. You never type into them, and they're always current because they're worked out fresh each time the item is shown.