Custom fields
A field owns one question and decides which answers are legal. It does not decide whether you are asked — that is the layout’s job.
Creating a field
- Go to Settings → Fields and select Create new field.
- Enter a name and description. The description becomes help text on the form.
- Choose the field type.
- Set Can be used in — Risk, Control, Incident, KRI. This is scope, not placement: it only decides which layouts may offer the field.
- Save.
Creating a field does not put it on any form. Nothing appears anywhere until you place it on a layout. This is deliberate — one field, many forms, placed differently in each — and it is the single most common point of confusion for new administrators.
Where select options come from
A single or multi-select field picks one of two modes:
| Mode | Use when | Stores |
|---|---|---|
| Type them here | A short list nothing else needs — Yes / No / Not applicable | The label |
| A custom asset list | The options are records you maintain elsewhere | The record’s identity |
Filtering the options
A list-sourced field can filter which records are offered, using an expression:
country = {{Country}} AND status = "Active"
Two kinds of reference, and the difference is the whole trick:
| Syntax | Resolves against | Example |
|---|---|---|
| A plain path | The record being filtered | status, country.status |
{{Field}} |
Another field on the record being filled in | {{Country}} |
Only {{Field}} creates a dependency, and dependencies are derived from the expression — never declared separately. There is no second place to keep in sync, which is why cascading fields cannot silently break here.
The editor validates the expression as you type and shows a live result count against a sample value, so you can see 2 of 14 offered before you save.
Stale values
When a filter changes, values captured earlier may no longer be legal. Each field chooses what happens:
- Keep it and flag (default) — nothing is deleted; the record shows a warning until somebody resolves it.
- Clear it — the value is removed.
Deleting and restoring
Deleting a field removes it from every layout and stops it being collected. Captured values are retained for a recovery window and the field can be restored.
Switching a field from “type them here” to a list changes how values are stored — from a label to a record identity. Existing values must be matched by label, and unmatched ones flagged. Plan this migration; do not do it on a field with a lot of history without checking the match report first.