> For the complete documentation index, see [llms.txt](https://docs.notionapps.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.notionapps.com/screens-and-components/types-of-screens/select-items.md).

# Select Items

Select Items is the screen type whose feature flag is `SELECT_RECORDS`. Users pick one or more Notion rows and return that selection to the screen that opened it — usually a form field or a workflow step — instead of opening a normal list.

This page is the canonical reference. It lives under **Types of Screens**, next to List and Details. Do not look for a second Select Items book under Automation.

## What this is / when to use it

Use Select Items when the user must **choose existing rows** and the app needs those ids back.

Good examples:

* A Create Form “Related projects” field opens Select Items so the user can pick projects from another database.
* A Work Queue action needs the operator to attach existing records before Complete.
* A multi-step form asks “which contract line items apply?” and must write a relation.

When **not** to use it:

* Users should browse and open a details page. Use [List (View Items)](https://docs.notionapps.com/screens-and-components/types-of-screens/list-view-items).
* Users should edit many rows in place. Use [List (Update Items)](https://docs.notionapps.com/screens-and-components/types-of-screens/update-items-form) and [bulk update](https://docs.notionapps.com/screens-and-components/types-of-screens/update-items-form#bulk-update).
* Users should create a new row. Use [Form (Add Item)](https://docs.notionapps.com/screens-and-components/types-of-screens/add-new-item-form).
* Users should claim automation work. Use [Work Queue](https://docs.notionapps.com/screens-and-components/types-of-screens/native-automation-and-operational-screen-guides/work-queue-screen).

```
List = browse rows.
Select Items = return a selection.
Update list = edit rows.
```

## Before you start

1. The source Notion database is linked. See [Manage linked databases](https://docs.notionapps.com/databases/manage-linked-databases).
2. You know which screen or component will **open** Select Items (a relation field, a button, or a screen action).
3. You know whether users may pick **one** row or **many**.
4. If the app is private, [screen visibility](https://docs.notionapps.com/screens-and-components/customize-a-screen/screen-visibility) and [data restriction](https://docs.notionapps.com/users/data-restriction) are already decided — Select Items respects both.

## Build it

1. Open **Screens → + New Screen**.
2. Choose the Notion database users will pick from.
3. Select the **Select Items** card (`SELECT_RECORDS`). Confirm.
4. Set the screen title users will see (“Choose projects”, not the database name).
5. Choose the [view type](https://docs.notionapps.com/screens-and-components/customize-a-screen/view-types-list-grid-calendar-board): list is the default; grid helps when the title image matters.
6. Add the columns users need to decide (title, status, owner). Do not add every property.
7. Turn on [in-app filters](https://docs.notionapps.com/screens-and-components/customize-a-screen/in-app-filtering) if the database is large. Prefer `PRE_DEFINED` chips for the two or three statuses people actually pick from.
8. In **Edit Navigation**, hide this screen from the tab bar / drawer unless users should open it on its own. Most Select Items screens are opened from a field and should be [hidden from nav](https://docs.notionapps.com/screens-and-components/app-navigation#hide-from-navigation).
9. On the form or button that should open it, set the reference / selection target to this screen.
10. Publish and test: open the form, tap the field, pick rows, confirm, and check the relation wrote back to Notion.

## Every control

| Control              | Options                             | What it does                                                                                                                        |
| -------------------- | ----------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- |
| Feature type         | `SELECT_RECORDS`                    | Builder card: Select Items.                                                                                                         |
| Source database      | Linked sheet                        | Rows the user can pick.                                                                                                             |
| View type            | `LIST`, `GRID`, `CALENDAR`, `BOARD` | Same view engine as other lists. Calendar/board are rarely useful for picking.                                                      |
| Selection mode       | Single / multiple                   | Multiple writes a relation or multi-value; single writes one page.                                                                  |
| Confirm button label | Text                                | What the user taps to return the selection.                                                                                         |
| Empty state          | Title + description                 | Shown when filters hide every row.                                                                                                  |
| Filters / sorts      | Builder filters                     | Restrict the pick list (for example only `Status = Active`).                                                                        |
| In-app filters       | `DYNAMIC` / `PRE_DEFINED`           | End-user narrowing. See [In-app Filtering](https://docs.notionapps.com/screens-and-components/customize-a-screen/in-app-filtering). |
| Scan                 | `BARCODE` / `QR` / `MULTI`          | Jump to a row by scanning. See [Barcode/QR](https://docs.notionapps.com/screens-and-components/barcode-qr-code-scanner).            |
| Screen visibility    | Role / user rules                   | Who can open the picker.                                                                                                            |
| Hide from nav        | On / off                            | Keep the picker off the main nav.                                                                                                   |
| Data restriction     | Inherit / disable on this screen    | Same rules as other lists. See [Data restriction vs filters](https://docs.notionapps.com/databases/data-restriction-and-filters).   |

Reference field modes that open this screen (on the form, not on Select Items itself):

| Reference add type | Meaning                                                       |
| ------------------ | ------------------------------------------------------------- |
| `NONE`             | Show related pages only. No picker.                           |
| `DIRECT`           | User types / picks inline without a full Select Items screen. |
| `SELECTION`        | Opens this Select Items screen and returns the chosen pages.  |

## What users see

1. They tap a relation or “Select items” control.
2. Select Items opens as a full screen (mobile) or a panel / split (desktop).
3. They search, filter, or scan, then tap rows. Selected rows stay highlighted.
4. They tap Confirm. The picker closes. The form shows the selected titles.
5. Submit on the form writes the relation (or the workflow step consumes the ids).

Cancel / back discards the in-progress selection and leaves the form unchanged.

## Limits and plans

* Select Items is a screen. It counts toward the app’s screen list like any other screen.
* The pick list is capped by the same list page size as other views. Use filters for large databases; do not expect the user to scroll thousands of rows.
* Users only see rows allowed by data restriction and screen visibility.
* Formula, rollup, created\_by, and last\_edited\_by can display on the picker but cannot be edited there. See [Notion property types](https://docs.notionapps.com/databases/notion-property-types).
* Hidden-from-nav screens still need a way in (field, button, or `go_to_screen`). A picker with no opener is a dead screen.

## Example

A delivery portal form **Add delivery** has a relation **Contracted scope**.

1. Add Select Items on the Scopes database. Title: **Choose scopes**. Hide from nav.
2. Builder filter: `Active = true`.
3. On the form, set the relation component to `SELECTION` and point it at **Choose scopes**.
4. Publish. A client opens Add delivery, taps Contracted scope, picks two scopes, confirms, and submits. Notion stores both related pages.

## Fix problems

| Symptom                                | Likely cause                                              | What to do                                                                                           |
| -------------------------------------- | --------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- |
| Select Items missing from + New Screen | Older app cache, or you are looking under Everyday chrome | Scroll the data screen group. Feature type is `SELECT_RECORDS`.                                      |
| Picker opens empty                     | Filters too tight, or data restriction hides every row    | Relax builder filters. Test with View as.                                                            |
| Confirm does nothing                   | No opener mapped the return target                        | Re-bind the form relation to this screen.                                                            |
| Users find the picker in the tab bar   | Hide from nav is off                                      | Turn it on. See [App Navigation](https://docs.notionapps.com/screens-and-components/app-navigation). |
| Relation stays empty after submit      | Property is read-only in Notion, or field map is wrong    | Check [Notion property types](https://docs.notionapps.com/databases/notion-property-types). Re-sync. |

## Related

Next: [List (Update Items)](https://docs.notionapps.com/screens-and-components/types-of-screens/update-items-form) if the job is edit-in-place, or [Relations](https://docs.notionapps.com/screens-and-components/relations) for the field that opens this screen.