Add conditional field formatting for numeric table and record fields

[Durocks]

Scope & Context

Twenty currently supports custom objects, fields, views, page layouts, front components, and command menu items through apps, but there does not appear to be a supported way to customize the native display renderer of an existing field in table/list views or record fields.

A common CRM/table use case is conditional numeric formatting. For example, a quote premium or price-difference field should be visually scannable:

• positive values render as bold green with an explicit + prefix
• negative values render as bold red with a - prefix
• zero/null values remain neutral
• sorting, filtering, editing, and API values remain numeric

Current Behavior

Numeric fields render as plain numeric values. App front components can render UI in side panels or page-layout widgets, and views can configure columns/order/filters, but apps cannot override the native field/cell renderer for a specific field.

For this use case, an app workaround would require adding a separate derived display field or widget, which does not modify the actual native table cell and can weaken sorting/filtering/editing semantics.

Expected Behavior

Twenty should support conditional display formatting for numeric fields, either as a core field/view configuration or as an app SDK extension.

Example desired behavior:

Stored value	Display
120	bold green +120
-45	bold red -45
0	neutral 0
null	empty/null display

The stored value should remain numeric. Existing table sorting, filtering, import/export, API reads/writes, and edits should continue to operate on the raw numeric value.

Possible API / Product Direction

Possible core metadata shape:

viewField: {
  fieldMetadataUniversalIdentifier: "...",
  formattingRules: [
    {
      when: { operator: "GREATER_THAN", value: 0 },
      textColor: "green",
      fontWeight: "bold",
      prefix: "+"
    },
    {
      when: { operator: "LESS_THAN", value: 0 },
      textColor: "red",
      fontWeight: "bold"
    }
  ]
}

Or an app SDK primitive such as:

defineFieldDisplayFormatter({
  fieldMetadataUniversalIdentifier: "...",
  objectUniversalIdentifier: "...",
  format: ({ value }) => ({
    text: value > 0 ? `+${value}` : String(value),
    color: value > 0 ? "green" : value < 0 ? "red" : "default",
    fontWeight: value === 0 || value == null ? "regular" : "bold",
  }),
});

Related Issues

• Remove custom file field maximum files limit and improve UX on attached files creation / edition / deletion #20942 discusses improving native custom field rendering UX for FILES fields.
• feat: make Notes column actionable in People table #21244 discusses making a table column actionable, showing that some column-level native behavior currently requires core feature work.
• App manifest cannot contribute view fields to views owned by another application (e.g. add app fields to "All Opportunities" #20886 and Imperative createViewField / createPageLayoutWidget assign the internal "Custom" application → subsequent app:install fails (cross-app orphans) #21423 are relevant to app extensibility limits around contributing view/layout metadata to entities owned by another application.

Why This Matters

For financial, trading, CRM, and operational workflows, users often need signed numeric values to be visually scannable without converting them into text fields or building parallel widgets. Conditional field formatting would preserve data integrity while improving day-to-day usability in dense table views.