Using the DashboardDataTableExtensionDefinition you can customize any existing data table in the Dashboard.
Use this API when you want to change a table that already exists in the Dashboard. You usually do not need to recreate the whole route just to add columns, fetch extra fields, change cell rendering, or add bulk actions.
A data table extension is targeted by pageId and, optionally, blockId:
Most list pages use blockId: 'list-table', so you can omit it. Detail pages and embedded tables can use a different block ID. For example, the product detail page has a product variants table with blockId: 'product-variants-table':
Use Dev Mode or the Extension Targets reference to find the pageId and blockId.
A display component replaces whatever the Dashboard would otherwise render in that column, including the built-in renderers that some columns come with. The price and priceWithTax columns, for example, are rendered as formatted money by default, and registering a display component for one of them replaces that rendering.
You can define your own custom components to render specific table cells:
The component receives the TanStack Table CellContext, including value, cell, row, and table. Use row.original when the cell renderer needs another field from the same row.
You can define bulk actions on the selected table items. The bulk action component should use DataTableBulkActionItem.
Bulk action components receive:
selection: the selected row datatable: the TanStack Table instance, useful for clearing selection after the actionIf your action mutates data, call refetchPaginatedList() after the mutation so the table refreshes.
The GraphQL queries used by list views can be extended using the extendListDocument property, and passing
the additional fields you want to fetch:
The extension query must extend the same top-level field as the table's original query. For example, the product list table uses the products field, so the extension document must also select products.
The Dashboard merges extension documents into the built-in list query, then still optimizes the query to fetch only visible columns and declared dependencies. If you extend the query with a field that should always be available to a custom renderer for another column, add that field as a dependency when you control the table definition. For existing tables, the most direct approach is to render the extended field as its own column with displayComponents, as shown above.
Use extendListDocument to fetch the field and displayComponents to render it. This keeps the built-in pagination, filtering, sorting, saved views, permissions, and future page improvements.
Target the nested table's blockId:
Only do this when the built-in page structure itself is wrong for your workflow. In that case, create your own route and navigation item. For column rendering, extra data, bulk actions, and adjacent content, prefer dataTables, pageBlocks, and actionBarItems.
Architecture reviews, custom plugin work, migrations, ongoing support. Get a hand from the team that builds Vendure.
Talk to the team