Question: Does conditional field visibility exist? (show/hide fields based on Select field value)

[ViniDAC]

Hi there,

We're currently setting up a self-hosted Twenty instance to evaluate it as a CRM for our recruitment business, and we're really impressed with what we've found so far — the metadata-driven data model and GraphQL API have been a pleasure to work with.

One thing we can't find is conditional field visibility — the ability to show or hide fields on a record's detail page and create form based on the value of another field (typically a Select field).

Our use case: We have a Job object with an "Employment Type" select (Permanent, Contract, FTC, etc.). Permanent jobs need salary and fee fields, Contract jobs need pay rate, bill rate, and margin fields. Currently all fields show regardless of the selection.

We've checked:

• Settings > Data Model > Fields — no visibility condition option
• The docs at docs.twenty.com
• GitHub issues and discussions
• The roadmap (noticed Custom Layouts V1 is planned for v2.0)

Does this feature exist somewhere we've missed? Or is it planned as part of Custom Layouts V1 or another upcoming release?

If it doesn't exist yet, we'd be happy to write up a proper feature request with use cases and proposed implementation. Just wanted to check first before duplicating anything.

Cheers

[BOHEUS]

@ViniDAC there's a discussion about the same feature as you mention but I don't recall it being planned #16182

CC: @Bonapara

[FelixMalfait]

Yes it's planned! Will be tackled within the "Layouts" track, not in Layouts v1 but that's one of the priorities that will come quickly after

[iamapay]

Hi @FelixMalfait,

Can we have a gross estimate as to when ?

[remihuigen]

Hi @FelixMalfait, is there already a spec on this feature? Would a proposal help move things along?

[FelixMalfait]

There isn't no, sorry. It isn't very complex but need to be designed properly. I'd say it's about one full day of work, maybe two with feedback, we already have all the foundations. We already have conditional visibility formulas for command menu items but I don't think it's exposed on the frontend, but could be a first inspiration. I'm not sure we have a similar formula editor but we load Monaco already so we could probably reuse that.

[remihuigen]

Why use a formula here instead of reusing the filter UI from index layouts? As I understand it, the condition is essentially just a filter expression evaluated against a single record. From a UX perspective, reusing the existing filter builder would feel much more intuitive and consistent.

On a separate note, I think the original post is somewhat narrow in scope. Conditional visibility is missing not only for individual fields, but also for:

• field groups
• widgets
• tabs

It seems worth designing this as a general layout capability rather than a field-specific feature. Supporting these other UI elements would make the feature much more complete.

[FelixMalfait]

My intuition was that it would apply on more than just the record properties (e.g. you might want to conditionally hide based on a role) so that the filter builder might not work. But it might be incorrect, for Row-level Permissions we have a filter builder that mixes things so you are most likely right that it'd be a better UX.

I agree it should also apply to tabs, widget level etc and have a global approach

[remihuigen]

Yes I agree, including user context - or maybe even app variables - in the conditional rendering makes sense.

[sashaluxdev]

Conditional field visibility is high on my list. Would be a gamechanger in capability.