A view is a saved configuration for how records of an object are displayed: which fields appear, their order, whether they’re visible, and any filters or groups applied. Use defineView() to ship pre-configured views with your app — typically a default index view for each custom object you create.
src/views/example-view.ts

Key points

  • objectUniversalIdentifier specifies which object this view applies to. It can be a custom object you defined or a standard Zambrite CRM object.
  • key: ViewKey.INDEX marks the view as the object’s main list view (the one an OBJECT navigation item opens).
  • fields controls which columns appear and in what order. Each field references a fieldMetadataUniversalIdentifier. To reference an auto-created system field such as createdAt, see Targeting System Fields.
  • You can also declare filters, filterGroups, sorts, groups, and fieldGroups for advanced configurations.
  • position controls ordering when multiple views exist for the same object.

Optional properties

All enums above are exported from twenty-sdk/define.

Filters

A view can ship with pre-applied filters. Each filter has three coordinates: the field being filtered, the operand (how to compare), and the value (what to compare against). All three must line up — using an operand that doesn’t apply to a field type will be rejected at sync time.

Supported operands per field type

Field types with similar names can use entirely different operands — SELECT and MULTI_SELECT being a common case.

Value shape per operand

The value field is always a JSON-serializable value, but its expected shape depends on the operand:

How views show up in the UI

A view by itself isn’t reachable from the sidebar. To make it appear there, pair it with a navigation menu item of type VIEW that points at the view’s universalIdentifier. That’s the canonical pattern: every custom object typically ships a default view + a sidebar entry that opens it.