☑️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).

• Users should edit many rows in place. Use List (Update Items) and bulk update.

• Users should create a new row. Use Form (Add Item).

• Users should claim automation work. Use Work Queue.

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.

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 and 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: 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 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.

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.
Scan	BARCODE / QR / MULTI	Jump to a row by scanning. See Barcode/QR.
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.

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.

• 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.
Relation stays empty after submit	Property is read-only in Notion, or field map is wrong	Check Notion property types. Re-sync.

Related

Next: List (Update Items) if the job is edit-in-place, or Relations for the field that opens this screen.