Views, Filters & Page Layouts

Relevant source files

The following files were used as context for generating this wiki page:

• packages/twenty-apps/internal/twenty-partners/src/skills/twenty-partner-design-doc/design-doc-doctrine.md
• packages/twenty-codex-plugin/references/publish-app/prepare-for-app-store.md
• packages/twenty-codex-plugin/references/develop-app/layout.md
• packages/twenty-codex-plugin/AGENTS.md
• packages/twenty-claude-skills/skills/twenty-record-presentation/SKILL.md
• packages/twenty-apps/internal/twenty-last-contact/CLAUDE.md

Views and Page Layouts constitute the primary presentation layer within the Twenty ecosystem. Views define how users discover and interact with collections of data—such as lists or boards—while Page Layouts dictate the visual organization of individual record details. These systems work in tandem with filters and sorting mechanisms to provide a structured, efficient user experience for managing complex CRM data models. Sources: packages/twenty-codex-plugin/references/develop-app/layout.md, packages/twenty-claude-skills/skills/twenty-record-presentation/SKILL.md

Views and Navigation

Views are the primary mechanism for data discovery and first-run experiences. They are categorized by their display type, such as tables (Index views), kanban boards, or calendars. Every view should be associated with a navigation menu item to ensure it is discoverable within the application's sidebar. Sources: packages/twenty-apps/internal/twenty-last-contact/CLAUDE.md, packages/twenty-codex-plugin/references/develop-app/layout.md

View Types and Selection

The selection of a view type depends on the audience and the specific data surface being exposed. While Table views are standard for general data management, Kanban views are often utilized for pipelines or status-based workflows. Sources: packages/twenty-apps/internal/twenty-partners/src/skills/twenty-partner-design-doc/design-doc-doctrine.md, packages/twenty-claude-skills/skills/twenty-record-presentation/SKILL.md

View Type	Typical Use Case	Audience
Table (Index)	General record management and scanning	All Users
Kanban (Board)	Pipeline management and stage tracking	Sales/Operations
Calendar	Task deadlines and event scheduling	Individual Contributors

Sources: packages/twenty-apps/internal/twenty-partners/src/skills/twenty-partner-design-doc/design-doc-doctrine.md, packages/twenty-apps/internal/twenty-last-contact/CLAUDE.md

Navigation Integration

A view without an associated navigationMenuItem is considered a technical debt or a hidden asset, as users will not be able to visualize it in the standard UI. Navigation entries should be named concisely to match the underlying data model and prioritized based on common workflows. Sources: packages/twenty-apps/internal/twenty-last-contact/CLAUDE.md, packages/twenty-codex-plugin/references/develop-app/layout.md

The diagram above illustrates the workflow required to make data accessible to end-users via the navigation system. Sources: packages/twenty-apps/internal/twenty-last-contact/CLAUDE.md, packages/twenty-codex-plugin/references/develop-app/layout.md

Filters and Sorting

Filters and sorting provide the logic for data retrieval within views. These mechanisms allow users to narrow down large datasets to relevant records, such as "Latest Opportunities" or "High Priority Tasks." Sources: packages/twenty-claude-skills/skills/twenty-record-presentation/SKILL.md

Sorting Logic

Sorting is typically performed on timestamp fields to determine "recent" activity. Standard practices include:

• updatedAt: Used for "recent activity" or "last modified" logic.
• createdAt: Used for "newest records" or "recent additions."
• Deterministic Fallback: If multiple records share a date, a secondary field like name or ID is used to maintain stable order.

Sources: packages/twenty-claude-skills/skills/twenty-record-presentation/SKILL.md

Presentation Formatting

When presenting filtered data, raw technical values (like ISO timestamps or UUIDs) must be translated into human-readable formats. Sources: packages/twenty-claude-skills/skills/twenty-record-presentation/SKILL.md

Raw Field	User-Facing Label	Format
createdAt	Created	Readable Date (e.g., May 5, 2026)
amountMicros	Amount	Currency (e.g., EUR 12,450)
opportunityStage	Stage	Title Case (e.g., Negotiation)

Sources: packages/twenty-claude-skills/skills/twenty-record-presentation/SKILL.md

Page Layouts

Page Layouts define the visual organization of a record page. They are designed to make a record's current state and next available actions easily scannable. Layouts are composed of sections, groups of fields, and specialized widgets. Sources: packages/twenty-codex-plugin/references/develop-app/layout.md

Layout Structure

Standard layouts should group related fields to minimize scrolling and keep critical status indicators visible at the top of the page. Layouts can also include "Canvas" tabs for full-page custom UI. Sources: packages/twenty-codex-plugin/references/develop-app/layout.md, packages/twenty-apps/internal/twenty-last-contact/CLAUDE.md

Front Component Widgets

App-defined front components are integrated into page layouts using a specific widget configuration. This requires a frontComponentUniversalIdentifier to link the widget to its code definition. Sources: packages/twenty-codex-plugin/references/develop-app/layout.md

// Example Widget Configuration in Page Layout
{
  universalIdentifier: 'example-widget-uuid',
  title: 'My Custom Widget',
  type: 'FRONT_COMPONENT',
  objectUniversalIdentifier: 'target-object-uuid',
  configuration: {
    configurationType: 'FRONT_COMPONENT',
    frontComponentUniversalIdentifier: 'front-component-uuid',
  },
}

Sources: packages/twenty-codex-plugin/references/develop-app/layout.md:27-38

UI Design Principles

Layouts and components must adhere to the Twenty design system:

• Responsiveness: Components should adapt to fixed widget dimensions unless intended for a Canvas tab.
• Editorial Restraint: Prioritize whitespace and clear typography over information density.
• States: Always include empty, loading, and error states for front components within a layout.

Sources: packages/twenty-apps/internal/twenty-last-contact/CLAUDE.md, packages/twenty-codex-plugin/references/develop-app/layout.md, PRODUCT.md

Technical Implementation

Development of these surfaces is managed through the Twenty CLI. The CLI handles the generation of UUIDs, SDK imports, and boilerplate code required for valid entity definitions. Sources: packages/twenty-apps/internal/twenty-last-contact/CLAUDE.md, packages/twenty-codex-plugin/AGENTS.md

CLI Commands for Layout Entities

Entity	CLI Command	Path
View	yarn twenty dev:add view	src/views/
Navigation Item	yarn twenty dev:add navigationMenuItem	src/navigation-menu-items/
Page Layout	yarn twenty dev:add pageLayout	src/page-layouts/
Front Component	yarn twenty dev:add frontComponent	src/front-components/

Sources: packages/twenty-apps/internal/twenty-last-contact/CLAUDE.md

Verification Workflow

After modifying layout entities, developers must synchronize the app changes with the remote instance. This is done using a one-shot sync command to ensure stability in the development environment. Sources: packages/twenty-codex-plugin/AGENTS.md, packages/twenty-codex-plugin/references/develop-app/layout.md

This sequence ensures that all layout changes are correctly registered and visually verified before deployment. Sources: packages/twenty-codex-plugin/AGENTS.md, packages/twenty-codex-plugin/references/develop-app/layout.md

Summary

Views, Filters, and Page Layouts form the core interaction layer of Twenty. By strictly separating collection-level discovery (Views) from record-level detail (Layouts), and supporting them with robust filtering and CLI-driven implementation, the system ensures a consistent and scalable user experience. Proper integration between navigation and views is mandatory for functionality, while layout design prioritizes clarity and responsive component behavior. Sources: packages/twenty-codex-plugin/references/develop-app/layout.md, packages/twenty-apps/internal/twenty-last-contact/CLAUDE.md