Repository navigation
Description
Title: Add board-level custom fields
✨ Feature Request
Is your feature request related to a problem? Please describe.
Cards often need a small amount of structured metadata that does not fit labels,
members or due dates: a workflow status, customer or ticket reference, story
points, a review date, or a yes/no flag. Labels can approximate some of these,
but they cannot keep the field name, value type and meaning separate.
This also matters for migration. We are moving a sizeable workspace from Trello,
where 14 boards currently use 36 custom-field definitions and 4,585 populated
values. Dropping them or flattening them into card descriptions would make the
cards harder to filter and maintain after the move.
Describe the solution you'd like
- Custom-field definitions belong to a board and support text, number,
date/time, checkbox and single-select values. - Board editors can create, rename, reorder and archive fields, choose whether a
value is shown on the card front, and manage ordered, coloured select options. - Card editors can set or clear values from the existing card side panel.
- Populated fields marked for the card front appear as compact named values on
board cards. - Board filters keep definitions under one top-level
Custom fieldsgroup,
then expose each field and its applicable controls. They support select and
checkbox values as well as text contains, number equals/range and date
before/after/range. - Card duplication, board templates and cross-board moves preserve values rather
than silently dropping them. - The existing Trello importer can bring across current definitions, options and
values.
There is no separate enable switch. The first field activates the UI for that
board; a board without fields stays unchanged. The existing board:edit and
card:edit permissions also seem sufficient, without adding a new RBAC area.
Describe alternatives you've considered
Using labels for every structured value mixes unrelated namespaces and does not
cover text, number or date values. Putting key/value lines in descriptions keeps
the text visible but loses validation, filtering and safe updates. A generic
plugin or formula system would be much larger than the immediate need and can be
built on top later if that direction makes sense.
Additional context
We are already trying this in our fork because preserving this workflow is part
of our Trello migration. The implementation is deliberately provider-neutral;
the Trello adapter is only one import path.
The overall field model is informed by Trello's custom fields. We have found
that model well considered in everyday use, and keeping its familiar concepts
makes migration easier without making the feature Trello-specific. It also
provides a useful foundation for small board automations. We are already
exploring how to migrate the automations our teams rely on into our fork,
although automation itself is outside the scope of this proposal.
Board cards with field values:
Editing populated values for all supported field types on a card:
The implementation is ready for review in #609 and remains available in the
feat/custom-fields
branch of my fork. It is rebased on the current upstream main and validated
locally. I am happy to adjust the product boundaries or split the implementation
if the maintainers prefer a different shape.
Related work
After opening this issue I found #534, which explores a broader schema-driven
board customisation system: YAML configuration, custom sections, placement in
the main panel or sidebar, built-in field overrides and several composite field
types. There is useful product work there, but its goal and persistence model
are different from this proposal. This issue focuses first on Trello-compatible
typed fields with stable definitions and options, filtering, lifecycle rules
and import support. The broader form-building ideas could be layered on top
rather than making YAML and a per-card JSON document the identity model for the
first version.
Implemented follow-ups in the current branch
- Show and populate custom fields while creating a card, with optional field
descriptions, placeholders and server-applied default values. - Add simple field sections and choose whether a field belongs in the main card
panel or sidebar. This would remain a flat, managed layout rather than an
arbitrary recursive form schema.
Possible follow-ups
- Consider multi-select and searchable/autocomplete fields after the initial
value and filtering model has settled. - Explore a member-valued field for roles such as supervisor or executor. Trello
does not have this field type, and it needs separate product decisions around
paused members, historical attribution and cross-workspace moves.
After #581 landed, the current branch reuses its nested navigation and selected
counts. Field definitions now sit below one top-level Custom fields entry
rather than adding every field to the first menu level. The screenshots above
have been refreshed.
Implementation ideas (optional)
The implementation uses board-owned definitions and options plus one typed value
row per card and field. Database constraints enforce the value shape and field
ownership. Definitions are projected once per board, while compact card values
carry IDs and typed values only. Filtering resolves each typed condition to a
compact matching-card set with selective indexed queries rather than per-card
lookups.
Field and option archival preserves existing values. Cross-board moves keep an
explicit source-to-target mapping so equal display names do not become identity,
and ambiguous matches fail rather than choosing silently. Current custom fields
from Trello are imported through the stock adapter with synthetic coverage; our
larger migration tooling remains separate from the proposed product feature.
The implementation has repository, API, web and import coverage, including
permissions, typed constraints, lifecycle races, card and board duplication,
cross-board mapping, filters, mobile interactions and Trello import shapes. It
has also been exercised with a production-shaped board containing 1,199 cards
with custom-field values and 2,279 value rows.
Would you like to work on this feature?
- Yes, I'd like to help implement this feature
- No, I'm just suggesting the feature
Activity
hjball commentedon Sep 7, 2026
This is desperately needed @bionicman
I think starting with the custom fields Trello supports make sense, but we should try to keep the scope of this as limited as possible for the first release.
We may need to tweak the UI/UX once merged but I'm happy for you to take a first pass at it. The most import things is that we have the structure in place and it's extensible.
feat(custom-fields): add downstream custom fields
feat(custom-fields): add downstream custom fields
feat(custom-fields): add downstream custom fields
feat(custom-fields): add downstream custom fields
feat(custom-fields): add downstream custom fields
feat(custom-fields): add downstream custom fields
feat(custom-fields): add downstream custom fields
feat(custom-fields): add downstream custom fields
feat(custom-fields): add downstream custom fields
feat(custom-fields): add downstream custom fields
feat(custom-fields): add downstream custom fields
feat(custom-fields): add downstream custom fields