🧑🔧List (Update Items)
List (Update Items) is the screen whose layout is UPDATE_LIST / feature UPDATE_RECORD_LIST. Users see a list of Notion rows and edit them without opening a separate update form. This page is also the canonical reference for bulk / multi-row update (UPDATE_MULTIPLE, cap 150 rows).
How-tos that mention “edit several rows” should link here. Do not create a second bulk-update URL.
What this is / when to use it
Use this screen when the job is change fields on rows that already exist, either one row at a time in the list or many rows at once.
Good examples:
Staff change Status and Owner on a work queue of requests without opening each details page.
A warehouse marks 40 items Received in one submit.
An approver updates a date on several line items after a decision.
When not to use it:
Users should only read rows. Use List (View Items).
Users should fill a long create form. Use Form (Add Item).
Users should pick rows and return them. Use Select Items.
Users should edit one rich record with sections and a stepper. Use Form (Update One Item).
View list = read.
Update list = edit in the list.
Bulk update = same values onto many selected rows, max 150.Before you start
The database is linked and synced.
The properties you will edit are writable. Formula, rollup, created_time, last_edited_time, created_by, and last_edited_by are display-only. See Notion property types.
You know which fields belong on the row vs which belong only in the bulk modal.
If guests can open the app, decide whether this screen is visible. Most update lists are private.
Build it
Create the update list
Screens → + New Screen.
Pick the database.
Choose List (Update Items).
Add input components for the fields users may change (status, owner, date, toggle).
Add view components for fields they should see but not edit (title, unique id).
Set filters so the list is the working set (for example
Status ≠ Done).Place the screen in navigation for the role that may edit.
Publish and edit one row as a test user.
Turn on bulk update
On the same screen, open Screen Actions / record actions.
Enable Update multiple (
UPDATE_MULTIPLE).Choose which fields appear in the bulk modal. Only include fields that are safe to stamp onto many rows (Status, Owner, a date). Do not include title or files unless you mean it.
Set the confirm label (“Update selected”).
Publish. In the live app, select two rows, open bulk update, set Status, submit. Confirm both Notion pages changed.
Every control
Screen
Feature / layout
UPDATE_RECORD_LIST / UPDATE_LIST
Update list screen.
View type
LIST, GRID, CALENDAR, BOARD
Same as other lists. Bulk select is most reliable on LIST.
Record actions
CREATE, UPDATE, DELETE, UPDATE_MULTIPLE
Which row actions appear.
Delete
On / off
Deletes the Notion page. Keep off unless the role may destroy rows.
Filters / sorts
Builder
Working set.
In-app filters
DYNAMIC / PRE_DEFINED
End-user narrowing.
Scan
BARCODE / QR / MULTI
Find a row by code.
Desktop split
Master-detail
List on the left, the selected row’s fields on the right. See Desktop view.
Bulk update
Enable Update multiple
Shows a select-rows + bulk editor affordance.
Fields in the modal
Only these properties are written on submit. Empty fields in the modal mean “leave this property alone,” not “clear it,” unless the control explicitly supports clear.
Confirm / cancel
Writes all selected rows in one request, or discards.
Cap
150 rows per submit (MAX_ROWS_FOR_MULTI_UPDATE).
Field-level (each input on the list)
Required
On / off
Blocks row save / bulk save when empty.
Disable editing
On / off
Display the value on the update list without allowing change.
Default value
NONE / EXACT / DYNAMIC (CURRENT_USER)
Used when creating from this screen, not when bulk-updating existing rows.
What users see
Single-row edit. The list shows editable controls on each row (or in the desktop split). Changing a value and leaving the field (or tapping Save, depending on the screen) writes that row to Notion.
Bulk update.
The user turns on selection (checkboxes).
They select up to 150 rows. Selecting more is blocked or the submit fails with a clear cap error.
They open Update selected.
The modal shows only the bulk fields. They set Status = Received.
They confirm. The app writes
UPDATE_MULTIPLE. Each selected page gets that Status. Other properties stay as they were.The list refreshes.
Limits and plans
150 rows per bulk submit. Split the work if the working set is larger.
Each write counts as a Notion page update. Large bulks can hit Notion rate limits; wait and retry the remaining rows.
Files, images, and signatures in a bulk modal are a bad idea: the same file would attach to every selected row.
People properties are stored as text in NotionApps (comma-separated names/ids). Bulk-stamping people is brittle. Prefer a User field or a relation. See Notion property types.
Data restriction still applies. Users cannot bulk-update rows they cannot see.
Autosave of the builder is unrelated to bulk update. If the builder itself fails to save, see Save failed.
Example
A warehouse list Receiving is an Update Items screen on Items.
Visible fields: SKU (view), Location (input), Received (toggle).
Bulk modal fields: Received, Location.
A clerk scans three boxes (
MULTI), selects those rows, opens Update selected, sets Received = on and Location = Dock A, confirms.Three Notion pages update. The list filter
Received = offdrops them from the working set.
Fix problems
Update multiple missing
Record action not enabled
Enable UPDATE_MULTIPLE on the screen.
Submit errors at 151+ rows
Cap
Select 150 or fewer. Filter first.
Some rows did not change
Row not selected, or property read-only
Check selection. Check field map.
Modal overwrote a field you meant to leave
You set a value on that control
Leave bulk fields untouched to skip them.
Builder help still opens Tawk
Old help URL
Product help now points at this heading.
Related
Next: Form (Update One Item) for a full-page edit, or View types to change how the list looks. Button vs form submit actions: Button component and Form submit redirection.
Last updated