Custom fields

Custom fields let you record something Kancil has no box for — a client reference, a contract number, a T-shirt size — without waiting for it to be built in.

How a field is defined

Each field has:

• a label, what you see on the record;
• a key, the stable identifier stored with the data. Kancil suggests one from the label. Changing a label later is safe; changing a key orphans the values already recorded under the old one;
• a kind, which decides the input;
• options, for the choice kinds;
• required, which makes the field mandatory on the records it applies to;
• a position, controlling the order fields appear in.

Define them in Custom fields settings. Fields are scoped to a record type, so a field you add for deals does not clutter tasks.

Choosing a kind

The kind is worth a moment's thought, because it decides what you can do with the values later. Free text accepts anything and is searchable but not groupable; a choice field constrains input to a list, which is what makes consistent filtering possible. If you will ever want to answer "how many are X?", you want a choice field, not text.

Custom fields versus tags

They overlap enough to be confused, and the distinction is worth keeping.

A tag is a label you attach to records of many types. It is optional, open-ended, and its whole purpose is grouping — see Tags, links and the knowledge graph.

A custom field is an attribute of one record type. Every record of that type has the field, whether or not it has a value, and it can be mandatory.

The test: if the answer is a property of this thing — a reference number, a category from a fixed list — it is a field. If the answer is which pile does this belong in, it is a tag.

Where the values live

Values are stored on the record, and travel with it: through search, into the API, and into any export. A field you delete stops appearing on records, but this is not a way to bulk-clear data — treat removing a field as a decision about the future, not a cleanup of the past.