> ## Documentation Index
> Fetch the complete documentation index at: https://docs.gavai.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Query your data
> Use runQuery to power Tables, DetailPanels, and KanbanBoards.
export const ErrorTable = ({errors}) =>
;
export const Eyebrow = ({label, tone = "default"}) =>
{label}
;
By the end of this guide your page reads typed, paginated rows from your workspace Postgres schema through the `runQuery` capability — with row-level access enforced automatically and no SQL written. You will declare a table, wire a **Table** block, enable sorting and filtering, connect click-through to a **DetailPanel**, and call `runQuery` directly for custom data fetching.
## Prerequisites
A gavAI workspace.A schema with at least one table. Create one in the Builder under **Workspace → Schema**.
## Steps
Define the table in the workspace schema. The schema is a JSON document that lives at the workspace level — the Builder exposes it under **Workspace → Schema**. A minimal `customers` table:
```json theme={null}
{
"schema": {
"customers": {
"fields": {
"name": { "type": "text" },
"email": { "type": "text" },
"status": { "type": "text" },
"created_at": { "type": "timestamp" }
}
}
}
}
```
Once saved, every block on every page in the workspace can reference `"schema_table": "customers"`. The platform validates queries against this schema at render time.
Add a **Table** block and point it at the table:
```json theme={null}
{
"block": "Table",
"props": {
"schema_table": "customers",
"columns": ["name", "email", "status", "created_at"]
}
}
```
The block fetches rows when the page loads. Column order follows the `columns` array; field names must match the schema exactly.
Add `sortable`, `filterable`, and `page_size`:
```json theme={null}
{
"block": "Table",
"props": {
"schema_table": "customers",
"columns": ["name", "email", "status", "created_at"],
"sortable": true,
"filterable": true,
"page_size": 25
}
}
```
With `sortable: true`, column headers become click-to-sort. With `filterable: true`, a filter bar appears above the table. `page_size` controls rows per page; users navigate with the built-in controls.
Add `on_row_click` to navigate to a detail page when a user clicks a row. The `{{id}}` token resolves to the clicked row's primary key:
```json theme={null}
{
"block": "Table",
"props": {
"schema_table": "customers",
"columns": ["name", "email", "status", "created_at"],
"sortable": true,
"filterable": true,
"page_size": 25,
"on_row_click": { "navigate": "/customers/{{id}}" }
}
}
```
On the destination page (`/customers/[id]`), add a **DetailPanel** block with `record_id_param: "id"`. The panel reads the URL parameter and loads the matching record. See [DetailPanel](/pageblocks/blocks/detail-panel) for the full prop reference.
When the built-in Table binding is not enough, invoke `runQuery` from a capability hook on the page. The full input shape:
```json theme={null}
{
"table": "customers",
"filter": { "status": "active" },
"sort": [{ "field": "created_at", "dir": "desc" }],
"limit": 50,
"cursor": null
}
```
```json theme={null}
{
"rows": [
{ "name": "Ada Lovelace", "email": "ada@example.com", "status": "active", "created_at": "2026-01-15T09:00:00Z" }
],
"next_cursor": "eyJpZCI6MTIzfQ==",
"total": 312
}
```
Pass `next_cursor` back as `cursor` on the next call to page through results. The `limit` maximum is **1000 rows per call**. Omit `total` from the input if you do not need a count — computing it costs a second query.
`runQuery` runs in the security context of the calling page. The active `authUser` determines which rows are returnable. For server-side scripts and automation, use the [public REST API](/api-reference/introduction); `runQuery` is designed for in-page data fetching.
Whether row visibility for anonymous users is controlled by a row-level attribute (such as a `public` field) or a schema-level grant is not specified in the public source. Confirm with the platform team before relying on either behavior.
## Troubleshooting
## What you built
You declared a `customers` table, wired a **Table** block with sort, filter, and pagination, connected row clicks to a **DetailPanel** via URL parameters, and called `runQuery` directly for a custom fetch. Row-level access is enforced automatically — the page only returns rows the current user is allowed to see.
## Next steps
Full input/output schema, filter DSL, pagination, and security context for runQuery.
Every prop the Table block accepts, including column configuration and action hooks.
Group records by a status field and let users drag cards between columns.