Tickbox (Multiple) (DB)
A set of tickboxes whose options are records in another datastore, with any number selectable.
Where to find it
Architect Panel → Data:
- Datastores — the datastore, then Table Designer to add or edit a field
Architect Panel → Data:
- Datastores — the datastore the options come from
It does not join
Multi-select fields store their selections as text rather than as a single reference, so they are not joinable. A report cannot join through this field and group by it the way it can with a single-select one.
That is not a defect — one value cannot point at three records — but it is the trade you are making. If "how many records are in each category" is a question you will ask often, a single-select field, or a proper linked datastore, will serve you far better.
What the database backing gives you
- The business maintains the list without an architect.
- Options can carry their own information and their own permissions.
- Renaming an option updates it everywhere it is displayed.
- Options can be deactivated rather than deleted.
The control constrains the list
This is the tension in this type. The database backing invites a growing list; the tickbox control needs a short one.
Every option is rendered, so a source datastore that grows to sixty records produces sixty tickboxes on the form. Nobody reads that, and the visibility that justified tickboxes over a multi-select dropdown is long gone.
Filter, and watch the count
Filter to active records, and check periodically how many that actually is. A form that was comfortable with twelve options and now has forty has quietly become unusable, and nobody reports it as a bug — they just stop reading it.
Once past a dozen or so, move to the multi-select dropdown.
Choose this over the dropdown when visibility matters
If the user needs to see the full set to answer well — a checklist drawn from a maintained list of checks — tickboxes are right and the list must be kept short. If they are tagging, the dropdown is right and the list may be long.
Deactivate rather than delete
The standard rule for database-backed options. A deleted record leaves historical selections pointing at nothing.
Consider whether it should be a datastore
The same question as any multi-select: if the pairing needs attributes — when, by whom, at what level — a linking datastore is the right shape and this field is not.
Order them
Because the options come from a datastore, their order comes from it too. Give the source a sort field rather than relying on whatever order records happen to be in, which is otherwise creation order and looks arbitrary.
Worked example
An accreditation datastore lists the standards an organisation holds, drawn from a maintained Standards datastore with an active flag and a sort order. Fourteen active standards render as fourteen tickboxes, which is at the upper limit — a review is diarised to move the field to a multi-select dropdown if the list reaches twenty.
Recommendations
- Keep the active list short — a dozen or so.
- Watch the count over time; it grows quietly.
- Give the source a sort order.
- Move to a dropdown once visibility stops being achievable.