How to Filter a Notion Database View

The Filter control, found in the toolbar above any database view, opens a condition-builder for narrowing the visible rows down to only those matching specific criteria based on the database's properties — there's no default global keyboard shortcut bound to opening it, so it's a mouse-driven action via the Filter button itself. **Filters are per-view, not per-database**: This is the detail that trips up the most people coming from spreadsheet tools. A single Notion database can have many different saved views (a table, a board, a calendar), and each individual view carries its own independent filter configuration — filtering the table view to show only rows where Status equals "In Progress" doesn't affect what the board view or any other view of that same database shows, since each view's filter is scoped to itself, not to the underlying data. **Building a filter condition**: Clicking Filter presents a property selector (choose which property to filter by), followed by a condition appropriate to that property's type — a select property offers "is" or "is not" against its available option values, a date property offers relative conditions like "is within the past week" or an exact date range, a checkbox property offers simply checked or unchecked, and a text property offers contains/doesn't contain/is empty style conditions. **Combining multiple filter conditions**: Adding more than one condition lets you choose whether all conditions must match (AND logic) or any one of them is sufficient (OR logic) for a row to appear — useful for something like showing tasks that are either overdue OR marked urgent, which requires OR logic between two otherwise independent conditions rather than requiring both simultaneously. **Related shortcuts**: Switching between saved views (no default keyboard shortcut, click the view tabs) is the natural companion action, since building several differently filtered views of the same database is usually more useful than repeatedly reconfiguring one view's filter back and forth. Sort, found in the same toolbar area as Filter, determines the order rows appear in once the filter has determined which rows appear at all. **Common mistake**: expecting a filter applied to one view to also apply when viewing the same database embedded or linked elsewhere on a different page — a linked database view (a separate embed pointing at the same underlying data) carries its own independent filter configuration too, completely separate from the original database's own views, so filtering one doesn't touch the other even though both are ultimately displaying rows from the exact same source data. **Filtering to build a personal dashboard**: a common practical pattern is creating a linked database view filtered to show only rows assigned to you, or only rows due this week, embedded on your own personal home page — since that filter lives on the linked view rather than the original database, your personalized filtered view doesn't affect what anyone else sees when they open the same underlying database from their own page. **Filtering by relation and rollup properties**: once a database has relation properties linking it to another database (tasks linked to a projects database, for instance), filter conditions can reference those related values too — showing only tasks whose linked project has a specific status, for example — which is considerably more powerful than a flat spreadsheet filter since it lets one database's view respond to data actually stored in a completely different, related database elsewhere in the workspace. **When a filter alone isn't enough**: for genuinely complex reporting needs — cross-referencing values across several relation hops, or computing something a simple property condition can't express — Notion's filter builder eventually reaches its limits, at which point exporting the database and working with the data in a spreadsheet tool, or using a formula property to precompute a derived value the filter can then check, becomes the more practical path forward rather than fighting an increasingly convoluted nested filter condition.