Data types & records

With data types you set up your own lists — events, products, team members — and display them anywhere on your site.

Example: a list as an overview

Show the items from my list as an overview of cards with a title and short description.

Why custom data types help

A single data type can power several very different pages. Products, for example, could show up as a filtered grid on a shop page and, at the same time, as a short "related items" list on a blog article — all from the same underlying records.

Data types pair naturally with dynamic pages: each record can automatically get its own detail page, generated from one template instead of a hundred manually built pages.

A common use case is collecting submissions through a form and turning accepted entries into records — think event registrations that later appear in a public overview.

Practical tip: start the records block simple — a sort order and a limit are usually enough. Add filters only once you know which ones visitors actually use.

Choosing fields that actually get used

The biggest design decision with a data type isn't the layout, it's the field list. Every field you add is a question someone has to answer when creating a record, so a type with thirty optional fields tends to end up with most of them empty. Start with the handful of fields a visitor genuinely needs to see or that a template needs to render, and only add more once a real gap shows up.

A common mistake is copying a field structure from a spreadsheet or an old CMS wholesale, including columns that made sense for internal bookkeeping but never appear on the public site. Separate what visitors need to see from what you need to track internally — the latter often belongs in a note field rather than a dozen structured fields nobody displays.

Data types across different kinds of sites

A recruitment agency might use a data type for vacancies, each with a location, a salary range and a closing date, rendered as a filterable list. A restaurant might use one for menu items, grouped by category and rendered with the table of contents block for quick navigation between sections on a long menu page. A conference site might use one for speakers and another for sessions, cross-referenced so each session page shows its speaker's photo and bio automatically.

What all of these share is the same underlying mechanism: define the shape once, then let every page that needs that content pull from the same source instead of retyping it.

Where people go wrong with lists

A frequent misconception is that data types are only for large catalogues. Even a list of three team members benefits from being a data type rather than three near-identical page sections, because adding a fourth person later is then a matter of adding one record, not editing a page's markup by hand.

The other frequent mistake is sorting and filtering logic that only makes sense to the person who built it. If visitors need to find something in a long list, check the search block or the pagination block before assuming a single long scroll is good enough — long unfiltered lists are one of the more common reasons visitors give up partway through a page.

For the technical shape of a record and how fields map to what you see on the page, see data types and records in the knowledge base.