UX improvement : Field Groups, better visibility

[n2ojim]

Scope & Context

We use Twenty CRM to manage complex records with many custom fields organized into field groups (e.g., "General", "Mandatory", "Website Display", "Internal Information"). Our primary use case is real estate property listings (Company records), where each property requires 30+ attributes grouped into logical sections.

As the number of fields per record grows, the current flat, compact layout of field groups becomes unreadable and overwhelming. Field groups are not visually distinct enough, cannot be collapsed/expanded, and the record detail view quickly turns into a long, undifferentiated wall of inputs. This issue affects all industries using Twenty for complex data models (real estate, construction, SaaS, healthcare, logistics, etc.) where records require many fields organized into logical sections.

Current behavior

1. Field groups are visually indistinguishable and cramped

Field groups in the record detail view are rendered as small, flat sections with minimal visual separation. There is no clear hierarchy between groups, making it hard to scan and locate relevant information quickly on objects like Company (property listings).

2. No collapse/expand functionality

All field groups are always fully expanded. Users cannot collapse a group to focus on another section. On records with many fields (e.g., a property listing with 30+ attributes across 5-6 groups), this forces excessive scrolling and cognitive overload.
[screenshot: A long Company record detail page showing all groups open simultaneously, requiring heavy scrolling to reach the bottom groups]

3. No visual grouping indicators (color, spacing, borders)

There are no color codes, distinct background shades, or strong borders to differentiate one group from another. The group label is rendered as plain text with the same styling as field labels, making it invisible at a glance. This is especially problematic when field groups are used in record widgets or side panels.

Expected behavior

1. Collapsible field groups (accordion behavior)

• Each field group should have a clear header with the group name and a chevron/arrow icon.
• Clicking the header toggles the group's visibility (expand/collapse).
• The collapse/expand state should optionally persist per user per object type.
• At least one group should be collapsible independently without affecting others.
• When all groups are collapsed, the record page becomes scannable at a glance.

Interactive Figma proposal: https://www.figma.com/make/yjwLgni1H0H0fqVZYl6jC2/Am%C3%A9liorer-l-UX-des-groupes-de-champs?code-node-id=0-9&p=f&fullscreen=1

2. Distinct visual styling per group

• Each field group should have a clearly separated container (card-like background, left border accent, or distinct header bar).
• Groups should have generous vertical spacing (margin) between them.
• Group headers should use stronger typography (bold, larger font size, or color) compared to field labels.
• The visual weight of a group header should make it immediately identifiable as a section delimiter.

3. Color-coded group indicators

• Introduce optional color coding for field groups (either as a left border stripe, header background tint, or tab color).
• This color code should be configurable in Settings > Data Model when creating/editing a field group.
• The same color code should appear when configuring record widgets or table views that reference these groups, giving visual consistency across the UI.
• Example: Blue for "General", Orange for "Mandatory", Green for "Website Display", Gray for "Internal Information".

4. Group visibility in record widgets

• When customizing record detail widgets (right panel, side widgets), field groups should be selectable as blocks rather than individual fields only.
• This allows users to drag entire "General" or "Internal Information" sections into widgets while preserving their grouped structure and color coding.
• Collapsed state in a widget should be independent from the main record view.

Technical inputs

• Frontend (Record Detail): Update the field group rendering component to wrap each group in a collapsible container (e.g., using a headless UI accordion or custom React state). Add isExpanded state per group, optionally persisted to localStorage or user preferences table (key = workspaceId + objectName + groupName + userId).
• Frontend (Styling): Update the group header component to use stronger typography (font-weight: 600, larger font-size) and add a container with border, background-color, or border-left accent styling. Introduce a color property (string, hex) to the field group metadata model and render it as a border-left-color or background-color on the group container.
• Backend (Metadata): Extend the fieldGroup entity/schema to include optional color (string, hex) and isExpandedByDefault (boolean) properties. Update GraphQL types (FieldMetadataGroup or equivalent), Zod validation schemas, and database migrations.
• Backend (Field Group Sync): Update the metadata sync logic (workspace:sync-metadata) to persist and validate the new color and isExpandedByDefault fields when syncing workspace metadata. Ensure custom field groups retain user-defined colors across syncs.
• Frontend (Data Model Settings): Add a color picker (hex input or preset palette) and an "expanded by default" toggle in the field group configuration UI (Settings > Data Model > Object > Field Groups).
• Frontend (Widget Builder): Update the widget field selector to present fields grouped by their field group, with group headers and color indicators, allowing bulk selection of an entire group. When a group is added to a widget, render it with its collapse/expand behavior and color code intact.
• Accessibility: Ensure accordion headers are focusable and keyboard-navigable (Enter/Space to toggle). Respect prefers-reduced-motion for expand/collapse animations.

[BOHEUS]

CC: @Bonapara

[Sakshamk17]

Hi I would like to work on this issue.
Please assign this to me.

[Bonapara]

Thanks for the idea @n2ojim! Will have a look

[mjamo-eng]

Strong +1 on this. Quick context up front: I'm new to GitHub and not a
developer. I'm setting up Twenty to replace a mature financial-services CRM
where dense, grouped record layouts are the daily driver, and I've been using
Claude Code to explore the codebase and try to build this out. So treat the
technical bits below as observations from that process, not authoritative
claims, and please correct anything I've got wrong.

A client record in our world runs 30-40+ fields across 8 groups (Identity,
Contact, Underwriting, Financial, Household, Coverage, Compliance, etc.), so
field-group usability is front and center for us. Building on @n2ojim's proposal:

1. Horizontal density matters as much as vertical.
Collapsible + color-coded groups solve the scroll problem. On a wide monitor the
other half is letting groups use the width: a per-group column option (1 / 2 / 3)
so Identity and Contact sit side by side instead of stacked. From what we found,
the CANVAS layout already honors per-widget gridPosition (column / span) on a
12-column grid, so the primitive exists for widgets; the gap seems to be bringing
it inside a single grouped fields widget. It would slot in next to the color /
isExpandedByDefault properties proposed here, as an optional per-group columns.

2. Some groups want full width and a mini-list.
Our "Coverage" group isn't a field list, it's 5 policies. The natural pattern is
a full-width group rendering a compact row per related record, each row expandable
to its detail (pairs with the inline-relational idea in #19900).

3. Configuration as a file, not just the GUI.
We tried defining our whole layout as code via the SDK app manifest (defineField
/ defineView with field groups / definePageLayout). The grid/multi-column part
genuinely works. But authoring grouped layouts this way was developer-heavy and
finicky for what's essentially "put these fields in these named groups in this
order." For a non-developer standing up a vertical, a simpler declarative file
(a YAML or markdown table of groups -> fields -> order/columns/color) that imports
without building an app or clicking through the GUI would turn this from a project
into a 10-minute task. Not instead of the GUI editor, a second front end on the
same metadata.

One observation that may be off-topic (and may belong in its own issue) - you
decide: while doing #3, we hit what looks like a bug. When a FIELDS widget is
installed via an app manifest, its configuration.viewId saves as null, even
though the built manifest.json has the correct view identifier. We confirmed it
across two syncs on a self-hosted v2.8.3 instance (the built file was right; the
stored value came back null). It looked like server-side resolution of that
serialized relation returning null rather than a manifest problem, since a
server-seeded view on the native Home tab keeps its viewId fine. That broke our
attempt to drive curated field groups from an app, and we worked around it with a
front-component. Flagging in case it's useful; happy to open a separate issue with
the details if that's the right home for it.

I spent considerable time on this with Claude Code, so I'm glad to share whatever
observations help. Happy to share a clickable prototype showing the collapse +
color + multi-column + full-width-group-with-expandable-policies patterns on a
real dense insurance record. Thanks @n2ojim for kicking this off.

[benweissbehavehealth]

I totally support this suggestion to add more detail and depth and color to these records layouts! Nice work @n2ojim !