The Collection List
The list page is where editors find, filter, and manage records — including selecting several at once to delete them in one step.
Every collection gets a list page: a searchable, sortable table of its records and the starting point for most editing work. This list is now the table operational view — see Operational Views and Table layout for the defineView counterpart that generates it. Collections without views still synthesize a list view so /collections/:slug never breaks.
This page covers what editors can do there day to day — find records, shape the table, act on a row, and act on many rows at once — and points you to the two faster ways to edit in bulk.
By the end you should know how editors navigate the list, how to control what it shows, and how bulk selection and deletion work.
Finding records
The search box queries the backend, not the rows already loaded in the browser. That means pagination, access control, filters, and search all stay in sync.
If you set admin.searchableFields, Dyrected searches those top-level fields. If you leave it unset, Dyrected falls back to a conservative inferred set: admin.useAsTitle first, then common text-like fields such as title, name, label, slug, email, caption, and description, plus rich text fields. The title column is a link, so clicking a record's title opens its edit form directly.
For narrowing rather than searching, the filter builder lets editors add rules against filterable fields. It uses a draft-then-apply flow: editors build up their filter rules first and apply them to the list when ready, so the table doesn't re-query on every keystroke.
If a collection has a status field, a status column is added automatically so editors can see draft/published state at a glance.
Shaping the table
The columns an editor sees come from admin.defaultColumns on the collection, falling back to the first few fields — or from the view's columns when you're in an operational view (defineView({ columns: [...] })). Editors can then reorder columns or toggle them on and off with the View button — and those choices are remembered per person via layout:collections:${slug}:view:${viewSlug} (see Routing and preferences for legacy view-columns: fallback). Because this is personal (with a team-wide default admins can publish), it has its own page: see Preferences for the full cascade and how to set defaults.
import {
defineCollection,
defineTextField,
defineSelectField,
defineDateTimeField,
} from "@dyrected/core";
export const Posts = defineCollection({
slug: "posts",
admin: {
useAsTitle: "title",
description: "Long-form content for the marketing site and docs.",
defaultColumns: ["title", "status", "publishedAt"],
searchableFields: ["title", "slug", "excerpt", "author"],
},
fields: [
defineTextField({ name: "title", label: "Title", required: true }),
defineTextField({ name: "slug", label: "Slug", unique: true }),
defineSelectField({ name: "status", label: "Status", options: ["draft", "published"], defaultValue: "draft" }),
defineDateTimeField({ name: "publishedAt", label: "Published At" }),
],
});If you set admin.description, it appears under the collection title on the list page. This is a good place for a short operational note such as what the collection is for, who uses it, or what editors should expect to find there.
Acting on a row
Each row has actions for the record it represents:
- Edit — opens the record's edit form.
- Delete — removes the record, with a confirmation step.
Both respect access control. Delete is disabled for a record the current editor can't delete, and — on an auth collection — editors can't delete their own account. If a whole action is missing for someone, that's their access rules at work, not a bug.
Acting on many rows at once
To act on several records in one step, editors select rows using the checkboxes (including a Select all checkbox in the header), then run a bulk action on the selection. Two are built in:
- Export Selected — download just the selected rows as a CSV, using the same format as a full CSV export. This is the quick way to pull an ad-hoc subset without exporting the whole collection.
- Delete Selected — remove the selected records.
Bulk delete respects per-record access just like the single-row action: from the selection, only the records the editor is actually allowed to delete are removed. If some selected records aren't deletable for that editor, they're skipped rather than blocking the whole operation.
Faster ways to edit in bulk
Deleting is one kind of bulk work; editing and moving data are others. Two features on the same list page cover those:
- Spreadsheet View — inline grid for the same records; now also a first-class
layout: "spreadsheet"view (/docs/model-content/operational-views/layouts/spreadsheet) rather than only a toggle on the legacy list. - CSV Import & Export — bulk-import records from a CSV, and export the whole collection to a CSV file.
Recommended path
Set admin.useAsTitle, admin.defaultColumns, and admin.searchableFields so the list is useful the moment a collection exists. Add admin.description when editors would benefit from a one-line explanation under the page title. Let editors tailor their own view with the View button, use single-row Edit/Delete for everyday changes, and reach for bulk selection when clearing several records. When the work is editing rather than deleting, move to Spreadsheet View or CSV Import & Export.