Notion Database & Table View Shortcuts
Notion's databases look superficially like a spreadsheet when displayed as a table view, but the underlying model is fundamentally different — every row is a full page in its own right, every column enforces a specific data type, and the same set of rows can be displayed through entirely different view types (table, board, calendar, gallery) without duplicating any data. The shortcuts here cover moving through and editing a database view, and understanding the row-is-a-page model up front avoids a lot of confusion for anyone arriving expecting spreadsheet-like freeform cells.
| Action | Windows | Mac | Description |
|---|---|---|---|
| Open a database record (page) | Click row, or Enter with row focused | Click row, or Enter with row focused | Opens the selected database row as its own full page — every row in a Notion database is secretly a complete page in its own right, capable of holding any block content beneath its properties, not just the values shown in the table's columns. |
| Move between cells in table view | Arrow keys / Tab | Arrow keys / Tab | Steps the focused cell across a table view one column or row at a time, similar in spirit to a spreadsheet but limited to whatever property columns are currently visible, since a database table is a structured view of pages rather than a freeform grid. |
| Create new database row | Ctrl+Enter (row focused) or click + New | Cmd+Return | Adds a new blank row (page) to the current database view, inheriting whatever filters are currently applied so the new row appears consistent with the filtered set you're looking at. |
| Edit a database property value | Click cell or Enter to open editor | Click cell or Return to open editor | Opens the appropriate input for that property's type — a date picker for a date property, a dropdown for a select property, a checkbox toggle for a checkbox property — since each column in a Notion database enforces its own data type rather than accepting arbitrary free text the way a spreadsheet cell does. |
| Open Filter menu | Click Filter (no default global key) | Click Filter (no default global key) | Opens the condition-builder for narrowing a database view to rows matching specific property criteria, saved per-view so different views of the same underlying database can show entirely different filtered subsets simultaneously. |
| Switch between saved database views | Click view tab at top of database (no default key) | Click view tab at top of database (no default key) | Jumps between different saved presentations of the same underlying data — table, board, calendar, gallery, timeline — each with its own filters and sort order, without duplicating the actual rows themselves, since all views read from the same single set of pages. |
Opening a database record (clicking a row, or pressing Enter with a row focused) reveals that every row is secretly a complete Notion page, not just a line of data — the property values you see in the table columns (a status, a date, an assignee) live at the top of that page as structured properties, but the page itself can hold any freeform block content beneath them, the same as any other Notion page. This is the single most important mental shift for anyone arriving from a traditional spreadsheet or CRM tool: a database row isn't a compact record you edit through a form, it's a genuine page that happens to also carry a few structured properties visible in the table.
Moving between cells in table view uses arrow keys or Tab, stepping the focused cell across the currently visible property columns one at a time — this works similarly to a spreadsheet's cell navigation on the surface, but it's constrained to whichever columns are currently shown in that specific view, since different saved views of the same database can show entirely different subsets of properties.
Creating a new row (Ctrl+Enter with a row focused, or clicking the + New button at the bottom of the table) adds a fresh page to the database, and critically, it inherits whatever filters are currently applied to the view you're looking at — if you're viewing a filtered subset showing only tasks assigned to you, a new row created from within that filtered view is automatically set up to match those filter conditions where possible, so it doesn't immediately disappear from view the moment you create it.
Editing a property value (clicking a cell, or pressing Enter to open its editor) opens whatever input type matches that specific property's configured type — a calendar picker for a date property, a searchable dropdown for a select or multi-select property, a simple checkbox toggle for a checkbox property, a person-search box for a person property. This type enforcement is what distinguishes a Notion database column from a free-text spreadsheet cell: you genuinely cannot type arbitrary text into a select-type property the way you could type anything into any Excel cell, since the property's type constrains what values are valid.
Filtering (via the Filter button, with no default global keyboard shortcut) opens a condition-builder for narrowing the current view down to rows matching specific criteria — filters are saved per-view rather than per-database, which means you can build several different saved views of the exact same underlying data, each showing a different filtered and sorted slice, without ever duplicating the actual rows themselves.
Switching between saved views (clicking the view tabs at the top of a database, again with no default keyboard shortcut) jumps between those different presentations — table, board (kanban-style, usually grouped by a select property like status), calendar (positioned by a date property), gallery (a visual grid, often used for image-heavy databases), and timeline (a Gantt-style view for date ranges). All of these views read from and write back to the exact same set of underlying pages, so editing a property from the board view updates the same data you'd see reflected in the table view — nothing about switching views ever creates a separate copy of the data.