One thing that has truly fascinated me and helped me realize why I love Notion is its dynamic nature. With its powerful filters, versatile formulas, smart automations, and countless template possibilities, Notion feels like a living, breathing system that evolves with your needs.
This tutorial serves as both a survey and practical demonstration of what I call "switches" in Notion. A switch occurs when you modify one elementβtypically a checkbox or statusβcausing another part of your system to automatically update and transform. It's similar to solving a puzzle in Legend of Zelda, where experimenting with different buttons reveals new pathways and opportunities to explore.
In this tutorial, we'll explore switches from basic to advanced applications. We'll start with familiar examples like filters, database views, and task managers. Then we'll progress to more sophisticated uses, such as leveraging switches as automation triggers and implementing dynamic property changes that affect every entry in a database through formulas. This guide is currently in development.
PROJECTED RELEASE: DECEMBER 2025
","category":"","type":"Notion","tags":["Tutorials"],"price":null,"url":"","payment_link":"","free_file":"","thumbnail_url":"/resource-images/","cover_image":"/resource-images/","featured":false,"status":"Don't Display Button","header_video":"","page_content":"This is a case study and reference guide, not a step-by-step tutorial. You'll see real examples from my production workspace with full complexity. Use this to understand the mental model, then adapt the patterns to your needs.
\nI've been working with Notion for years now, and one thing keeps coming back to me: the way this system handles data is genuinely fascinating. Not in a "look at this cool tech" way, but in a "this actually changes how I think about organizing work" way.
With filters, formulas, automations, and the way you can template literally anything, Notion feels less like software and more like a living system. It adapts. It grows with what you need.
This tutorial is my attempt to break down what I call "switches" in Notion - which is basically when you change one thing (usually a checkbox, status, or select property) and watch another part of your system automatically transform. Once you understand how switches work, you start seeing them everywhere in your workspace, and suddenly you're building systems that do exactly what you need without all the manual work.
Here's what I think is really powerful about Notion: you can log entries, summarize them to new databases, and display everything differently based on status - which gives you relevance and power without maintaining some nightmare of complexity.
There's this sweet spot between letting the software control your experience (because the system actually works) and having ultimate freedom to build what you need for the right moment.
Now, Notion gives us a lot of capabilities, but honestly? It can be restrictive at times. The next step beyond this is probably building your own software, or finding another tool that goes further - but those tools usually aren't as intuitive.
Notion blends the intuitive side of what you should have with almost all the customization you actually need. It gives you guardrails so you don't go off the deep end and make something that destroys what you're trying to create.
The makers of Notion have done their own software engineering and database design, so they know what works and what doesn't from experience. This is an easy, interactable experience - which is why I still promote the product as much as I do.
\nSwitches let you control what's relevant at any given moment. Instead of rigid folder structures or duplicate data everywhere, you get one source of truth with multiple ways to view and interact with it.
Before we get into the actual switches, let me clarify how they fit into Notion's bigger picture. I think this helps avoid confusion later.
Dynamic systems are Notion's overall capability where data edited in one place automatically updates everywhere else in your workspace. Change a database property, and that change shows up in every view, formula, and page that references it. This is the foundation that makes everything else possible.
\nFiltering is how you control what displays in a database view. You set criteria (like "Status is Active" or "Due Date is within 1 week") and only matching entries appear. Filters are static rules you configure - they don't change unless you manually edit them.
\nFormulas calculate and display dynamic information based on property values. Automations trigger actions when properties change, updating other properties automatically. Together, these are the outputs that respond to changes in your system - they make your workspace intelligent and reactive.
\nSwitches are properties you actively change that trigger all of the above to respond. A switch controls filtering (what displays), formulas (what calculates), and automations (what updates automatically). Switches make your dynamic system respond to your immediate needs by controlling what's relevant right now.
Think of it this way:
Traditional file systems like OneNote force you to manually organize folders and files. Files stay in one place, and you're constantly navigating between folders looking for things.
With Notion's database approach combined with switches, when you edit something in one place, it edits everywhere in your system. More importantly, switches let you control what subset of that information is relevant at any given moment without losing the full dataset.
The data stays the same. Only what you see changes.
You're not moving or copying data. You're controlling which subset is visible at any given moment through intelligent switches.
\nSwitches work in a simple framework: you change an INPUT property, which triggers a change in OUTPUT displays.
INPUT SWITCHES (what you change):
OUTPUT SWITCHES (what changes in response):
The power comes from combining different inputs with different outputs. A status property can trigger all three outputs simultaneously - filtering views, changing formula results, and launching automations.
Alright, let's talk about the properties you actively change to control your system. I'm going to walk through the main types and when to actually use each one - because honestly, choosing the wrong property type is one of the most common mistakes I see.
Why Checkboxes Matter for Switches
The checkbox is the simplest and fastest switch in Notion. It's binary: unchecked or checked, no or yes, false or true.
Here's why this matters: checkboxes require only one click to activate. No dropdown menus, no selecting from options - just immediate action. This speed makes checkboxes essential for rapid filtering, quick toggles, and situations where you're moving fast through your workflow.
The power of immediate action cannot be overstated. When you're triaging tasks during a meeting, flagging urgent items, or marking things complete, that single-click checkbox is the difference between fluid workflow and friction.
The Definition: Binary Control
A checkbox represents boolean logic - true or false, yes or no, on or off. This simplicity is its strength. There's no ambiguity, no in-between state, no decision paralysis. You check it or you don't.
In switch terminology, checkboxes are your rapid-fire controls. They're the light switches of your Notion workspace - immediate, clear, and require zero thought to operate.
In switch terminology, checkboxes are your rapid-fire controls. They're the light switches of your Notion workspace - immediate, clear, and require zero thought to operate.
Property Type: Checkbox (Boolean)
States: Two (checked/unchecked)
Best for: Immediate one-click actions
Speed: Instant (fastest switch type)
\nUse checkboxes when you need:
Why use a checkbox instead of a status?
Checkbox: Single click = immediate action. You click once and the switch activates instantly.
Status: Click + choose option = two-step process. You click to open the menu, then select which option you want.
When you need something to happen immediately with one click, use a checkbox. When you want defined text labels or emoji representations with multiple workflow stages, use a status.
\nDon't use checkboxes when:
Real-World Example: Urgent Flag System
In my task management system, I use a checkbox for "Urgent" instead of a status property. When something becomes urgent during a meeting or call, I need to flag it immediately with one click - not click to open a menu, then select "Urgent" from options.
The checkbox lets me instantly filter to show only urgent items in my daily view. If I used a status, the two-step process would slow down my workflow when I'm moving quickly through tasks.
The status property is probably the most common and most powerful type of switch you'll use. This is where you create properties that move from "To Do" to "In Progress" to "Done".
The Real Power: Default Values
Here's the most important reason to use status properties: status properties can automatically assign a default value when you create a new entry.
When you create a new task in your database, you can have it automatically set to "Not Started" or "To Do" without any manual input. This is huge for maintaining consistency across your system, especially when working with templates or quick captures.
Select properties don't have this capability - they start empty by default. If you need automatic default values, status properties are the only choice.
Property Type: Status
States: Multiple (grouped into To Do, In Progress, Done)
Best for: Workflow progression and multi-stage processes
Flexibility: High (unlimited custom options)
\nUse status properties when you need:
The status property looks similar to the select property - both let you choose one option from multiple text options.
The key differences:
Don't use status properties when:
The Three-State System
Notion's status properties are built around a three-state workflow model. Every status property organizes its options into three groups:
You can create as many custom status options as you need within these three groups. For example, your "To Do" group might contain "Not Started," "Backlog," and "Waiting," while your "In Progress" group might have "Active," "In Review," and "Testing."
Why the Three-State System Matters
The grouping structure helps Notion understand workflow progression. Board views automatically use these groups to organize columns. Automations can trigger based on group changes (like "when moved to Done"). The visual organization makes it immediately clear where something is in your workflow
Real-World Example: Multiple Status Switches
In my workspace, I use status properties for multiple switch types:
Text properties can work as switches when you need maximum flexibility or are working with complex technical requirements.
Why Text Properties Can Be Switches
Unlike status or select properties with predefined options, text properties accept any value. This makes them useful for dynamic switching scenarios where values are generated programmatically or need to integrate with external systems.
Unlike status or select properties with predefined options, text properties accept any value. This makes them useful for dynamic switching scenarios where values are generated programmatically or need to integrate with external systems.
Property Type: Text
States: Unlimited (any text value)
Best for: Technical edge cases and system integration
Flexibility: Maximum (no predefined options)
\nUse text properties as switches when you need:
Why status and checkbox are usually better:
Bottom line: Text properties are valid switches when their flexibility solves a specific technical problem that status or select cannot handle. For everyday manual switching, stick with status or checkbox.
\nThe properties below CAN work similarly to switches in dynamic systems, and you can filter by them, use them in formulas, and trigger automations when they change.
However, they serve bigger purposes than just switching - they're fundamental to how you structure and organize information in Notion. Their primary purpose isn't switching; it's assignment and data architecture.
For dedicated switching functionality, use status, checkbox, or (when justified) text properties.
\nA note on button properties: Technically, button properties are an input - you click them to trigger actions. However, they're really just a physical interface for automation switches, so we treat them as part of the automation output system rather than a separate input type.
Select properties look similar to status properties - both offer dropdown selection from multiple options. But select is designed for static categorization and tagging, not workflow switching.
Why Not Use Select for Switches?
Use select properties for:
If you're building a switch system, use status properties instead. Select can work in dynamic systems, but it's missing the key features (defaults, workflow groups) that make status properties ideal for switching.
\nPerson properties are for assigning responsibility and tracking ownership. When you assign someone to a task, you're designating who owns that work - not flipping a switch.
Why Person Properties Aren't Really Switches:
You can use person properties in dynamic systems:
Switching: Changing status from "To Do" to "Done" (state change)
Assignment: Changing person from John to Sarah (ownership change)
Both work in dynamic systems, but switching is about workflow state, assignment is about responsibility.
\nRelation properties build connections between databases. When you relate a task to a project, you're establishing a data relationship - not controlling what displays.
Why Relation Properties Aren't Really Switches:
You can use relation properties in dynamic systems:
Switching: Changing status to control visibility (workflow control)
Relating: Connecting task to project (data organization)
Relations enable filtering and dynamic behavior, but their main job is structuring your database architecture.
\nThe following property types CAN technically be read by formulas or automations, but are not recommended as manual input switches:
Now we get to the fun part - what actually happens when you flip a switch. I'm going to start with the simplest applications and build up to the more complex stuff progressively.
This is the simplest and most common use case for switches, and honestly, it's probably where you should start if you're new to this. When you change a property value, different views show or hide entries based on filters.
When you change a property value, different views show or hide entries based on filters.
Output Type: View Filtering
Complexity: Beginner-friendly
Best for: Organizing and decluttering databases
Requirements: None (works in all Notion plans)
\nUse view switching when you need:
The Fundamental Concept
You have one database with all your data. You create multiple views of that same database, each with different filters. When you change a switch property, entries appear in some views and disappear from others.
The data stays the same. Only what you see changes.
You're not moving or copying data. You're controlling which subset is visible at any given moment.
\nDon't use view switching when:
Simple Example: Show/Hide Completed Tasks
Let's start with the most basic switch setup:
When you check a task as done, it instantly disappears from Active Tasks and appears in Completed Tasks. You didn't move anything - the filter did all the work.
Now let's add more options with a status property:
Change the status property, and projects automatically move between views.
I use status switches to control what appears in my project views:
The same projects exist in the database, but I see completely different subsets based on which view I'm in.
\nAdding Context-Aware Properties
Here's where view switching gets more powerful: you can show different properties in different views based on what's relevant.
In my task system:
The switch (changing status to "Done") not only moves the task between views, but also changes what information displays because each view is configured differently.
Once you understand view switching, the next level is using switches to change what formulas calculate. The same formula property shows different results based on switch states.
The same formula property shows different results based on switch states.
Output Type: Formula Calculations
Complexity: Intermediate
Best for: Dynamic data displays and context-aware calculations
Requirements: None (works in all Notion plans)
\nUse formula switching when you need:
Don't use formula switching when:
This is where things start getting really interesting - and honestly, once you understand this, you can build some incredibly sophisticated systems.
Starting Simple: Basic IF Statements
Let's begin with a straightforward formula that responds to a checkbox:
if(prop("Urgent"), "π₯ HIGH PRIORITY", "Normal")This formula checks the "Urgent" checkbox. When checked, it displays "π₯ HIGH PRIORITY". When unchecked, it displays "Normal". The switch (Urgent checkbox) changes what the formula outputs.
Building on That: Multiple Conditions
Now let's add a status property into the mix:
if(prop("Status") == "Active", "Working on this now",
if(prop("Status") == "Planning", "Not started yet",
"Something else"))The formula checks the Status property and outputs different text based on which status is selected. Change the status (flip the switch), and the formula result changes.
Here's a practical example. You have a checkbox called "Show Today Only":
if(prop("Show Today Only"),
dateBetween(now(), prop("Due Date"), "days"),
dateBetween(now(), prop("Start Date"), "days"))When the checkbox is checked, the formula shows days until due date (relevant for active tasks).
When the checkbox is unchecked, the formula shows days since start date (relevant for tracking overall progress).
Same formula property, different calculations, controlled by a simple checkbox switch.
The formula doesn't change. The formula result changes based on the switch value.
This means you can have one formula property that serves multiple purposes depending on context.
\nNow let's get more sophisticated. You want to switch between showing different time tracking metrics:
if(prop("Display Mode") == "Sessions", prop("Session Time"),
if(prop("Display Mode") == "Estimates", prop("Estimated Time"),
prop("Goal Time")))You have a status property called "Display Mode" with three options: Sessions, Estimates, Goals.
The formula checks which option is selected and displays the corresponding time property. One switch, three different data points displayed.
I have three elements for tracking:
I use a switch to flip between what's relevant right now instead of having sessions, estimates, and goals all showing simultaneously.
Examples of what I can toggle:
Once your formulas get complex with multiple conditions, you'll want to use LETs to keep them organized.
Here's the same time tracking formula using LETs:
let(
mode, prop("Display Mode"),
sessions, prop("Session Time"),
estimates, prop("Estimated Time"),
goals, prop("Goal Time"),
if(mode == "Sessions", sessions,
if(mode == "Estimates", estimates, goals))
)The LETs formula lets you:
This becomes essential when you're checking multiple switch properties and calculating different results based on various combinations.
Formula Switching Philosophy
The key insight: formulas let switches control not just what you see, but what gets calculated. This transforms switches from simple show/hide tools into dynamic information processors.
This is the most advanced application - using switches to trigger automations that change other properties automatically. This goes beyond filtering views or calculating formulas. Automations actually modify your data.
Automations actually modify your data.
Output Type: Automated Property Changes
Complexity: Advanced
Best for: Workflow automation and cascading updates
Requirements: Notion Plus plan or higher ($10/month annually)
\nUse automation switching when you need:
To access database automations, you need the Notion Plus plan or higher ($10/month annually).
Why automations are different: Formulas calculate and display information. Automations actually change property values. This distinction is crucial for how you build your systems.
\nDon't use automation switching when:
Simple Automation: Two Inputs, One Output
Let's start with the clearest automation example: the Eisenhower Priority Matrix.
You have two checkbox switches:
You want a "Priority" select property to update automatically based on those two checkboxes.
The automation triggers when: Either checkbox changes
The automation action: Set Priority based on combination:
You could write this as a formula, but the automation actually changes the Priority property itself. This means:
Formulas: Calculate and display results, but don't change actual property values
Automations: Change the actual property values, which triggers other system behaviors
Use automations when you need the changed value to trigger something else (another automation, integration, or manual workflow).
\nIntermediate: Conditional Property Updates
Let's build on that. You want page names to update automatically, but only when preparing invoices.
Setup:
Automation 1: When Status changes to "Preparing Invoice" β Check "Show Time in Name"
Automation 2: When "Show Time in Name" is checked β Add time tracking info to page name
This creates a two-step automation chain where the status switch triggers a checkbox switch, which triggers the actual page update. You control when the complexity activates.
Advanced: Multi-Property Cascading Updates
Here's where automations become powerful for complex workflows.
When a project Status changes to "Complete":
One switch (Status β Complete) triggers a cascade of property changes that automate your entire completion workflow.
A Note on Button Properties
Technically, button properties are an input - you click them to trigger actions. However, they're really just a physical interface for automation switches. A button executes pre-configured automation logic with one click, so we're treating them as part of the automation output system rather than a separate input type.
Automation Strategy
The key to good automation switching:
Automations are powerful, but they can make your system harder to understand if overused. Use them for repetitive multi-step processes where manual work would be tedious.
Each example below demonstrates a specific switching concept, progressing from simple to advanced implementations.
Demonstrates: Pure view grouping and sorting with status property for visual organization
This is the clearest example of database view switching at its most fundamental - using a status property purely to control how entries are visually organized within a single view through grouping, without any formulas or automations.
How It Works:
The "Pin [A]" status property controls where tasks appear in my main view by using Notion's native grouping feature. The view groups by Pin [A] status and hides empty groups.
This is view switching in its purest form - no formulas, no automations, just native Notion grouping. The Pin status property simply controls visual organization through the view's group-by feature.
\nDemonstrates: Pure database filtering with checkbox switches - the foundational view switching pattern
This is the most basic switch pattern - one checkbox property controlling visibility across two views through filtering alone. No formulas, no automations, just clean view-based switching.
How It Works:
I have a Tasks database with one checkbox property called "Done". I create two views:
When I check the "Done" checkbox, the task instantly disappears from Active Tasks and appears in Completed Tasks.
This is the foundational switch pattern. One input (checkbox) controls visibility across two views. Every more complex switch system builds on this basic pattern.
\nDemonstrates: Status property distinguishing urgency type rather than workflow state
This example shows how status properties can represent categorization that affects filtering behavior without being part of a workflow progression. The Hard/Soft distinction is about the nature of the deadline itself.
How It Works:
In my Actions List database, some are hard deadlines - external commitments that cannot be moved (client presentations, event dates, regulatory filings). Others are soft deadlines - internal targets that provide structure but can be adjusted if needed.
The "Hard Deadline?" status property creates a fundamental distinction that affects how I filter and prioritize work.
The Hard/Soft distinction changes filtering behavior without representing workflow progression. This switch categorizes the nature of the commitment, which fundamentally affects how you prioritize and filter.
\nDemonstrates: Automation-driven property updates based on multiple checkbox inputs
Two checkbox switches (Urgent + Important) automatically update a Priority property through automation. This shows how automations can combine multiple inputs into a single calculated output.
How It Works:
I have two checkboxes that trigger an automation to set a Priority select property:
Two simple checkbox inputs create four distinct priority categories through automation. The automation changes the actual Priority property (not a formula), so I can filter views by it and other automations can trigger based on it.
\nDemonstrates: Formula calculations for controlling gallery card content display
This example uses formulas to control what displays inside gallery cards - specifically the Main Entry text property and contextual information pulled from relation properties and formatted via concat.
How It Works:
The formulas use concat (via .map() and .join()) to extract names from various relation properties and format them into readable lists based on which switch options are selected.
Example Formula:
let(
showHide, prop("Show Hide"),
projects, prop("Projects").map(current.prop("Name")).join(", "),
if(showHide == "Show All",
"π Projects: " + projects + "...",
if(showHide == "Show Some",
"π " + projects,
""))
)Two independent status switches control different aspects of gallery card display. The formulas dynamically extract and format information from relation properties using concat, giving you complete control over what displays in each gallery card.
\nDemonstrates: Multiple independent switches for granular control with formula-generated output
Instead of one switch controlling TO/BCC, this system uses three separate status switches to give precise control over email recipient placement.
How It Works:
Three independent status switches each control exactly one email field. A formula reads all three switches and pulls the appropriate contact lists from related databases, then formats everything as ready-to-copy email recipients.
This is a formula property that opens your email client automatically when clicked. You can also use a button property that triggers an automation to send email directly from Notion.
Three independent switches provide maximum flexibility. Instead of trying to encode all TO/CC/BCC combinations into one property (18+ options), each field gets its own simple two-option switch.
\nDemonstrates: Text formula properties as switches for navigating deep relational complexity (4+ database layers)
When your database architecture goes 4+ layers deep with complex many-to-many relationships, text properties generated by formulas become essential navigation tools.
Why Text Properties Become Necessary:
Text properties flatten complex relational data into filterable, displayable values. These text strings become switches - you can filter by them, use them in further formulas, trigger automations, and display them to users who might not have permission to see underlying relations.
\nDemonstrates: Complex formula switching with multiple interacting properties and automations
One formula property dynamically shows different time metrics (Sessions, Estimates, Goals) based on a single status switch, with optional automation chains and multiple interacting properties.
How It Works:
I have three different time properties but only want to see one at a time depending on context. The formula uses LETs to organize complex conditional logic:
let(
mode, prop("Display Mode"),
sessions, prop("Session Time"),
estimates, prop("Estimated Time"),
goals, prop("Goal Time"),
if(mode == "Sessions",
format(sessions) + " hrs worked",
if(mode == "Estimates",
format(estimates) + " hrs estimated",
format(goals) + " hrs goal"))
)Enhanced with automations: Status changes can trigger cascading automation chains that update related properties, time calculations, and dashboard displays.
One status property switch controls what a formula calculates and displays. Instead of having three separate time properties cluttering my database view, I have one "Time Display" property that shows the relevant metric. The optional automation layer adds even more dynamic behavior.
\nDemonstrates: Most complex - backend collector system with robust formulas and dual independent switches
This is the most sophisticated switch system - two independent status switches working together with multiple supporting properties, rollups, and complex filtering logic to create a backend collector that manages workspace-wide visibility.
How It Works:
My Compiled Lists Wiki database tracks all databases and systems in my workspace. The two status switches work independently but complementarily:
These switches don't depend on each other, creating maximum filtering flexibility.
Two independent status switches create flexible visibility control without complex conditions. Instead of one switch with 6+ options trying to encode all combinations, each switch handles one dimension of visibility. This separation means simpler option sets, flexible combinations, independent updates, and easier filtering.
\nDefault to Status for most switches - it has the functionality of multiple property types and can be as complex or simple as you need.
Use Checkboxes when you need immediate one-click action without choosing from options.
Avoid Multi-Select for switches - they become cumbersome with filtering. Use AND statements with separate properties instead.
\nWhen building database views, use the Advanced Filter instead of regular filters - it's easier to track ANDs and ORs.
Don't create 100-200 properties. Most overly complex systems come from unnecessarily complicated filtering. Keep it simple.
\nMaster LETs first before building complex switch formulas. The variable system makes formulas readable and maintainable.
Start simple with basic IF statements. Build complexity gradually. If you get stuck, step back and simplify.
Learn CONCAT for combining text elements - it works smoothly with LETs for dynamic displays.
\nYour switch system should make finding information easier, not harder.
You want it to be like finding a light switch - there it is, click, you get what you need. Not a puzzle to solve every time you want information.
If you find yourself confused about which switch does what, simplify immediately.
\nSwitches in Notion are one of the more complex features - along with metadata, relations, formulas, and rollups - that I consider integral to actually using Notion effectively.
There are many other cases you can use switches for, and you can make them as complex as you want. But remember:
Start with status properties and checkboxes
Master the LETs formula before getting fancy
Keep it simple - your system shouldn't be a puzzle
Use database views creatively with Advanced Filters
Think about what's relevant in the moment
Let automations do the heavy lifting when possible
With switches, you're not just organizing information - you're creating a workspace that adapts to you, showing you exactly what you need, when you need it.
That's the true power of a dynamic system controlled by intelligent switches.
\nThis is a case study and reference guide, not a step-by-step tutorial. You'll see real examples from my production workspace with full complexity. Use this to understand the mental model, then adapt the patterns to your needs.
\nI've been working with Notion for years now, and one thing keeps coming back to me: the way this system handles data is genuinely fascinating. Not in a "look at this cool tech" way, but in a "this actually changes how I think about organizing work" way.
With filters, formulas, automations, and the way you can template literally anything, Notion feels less like software and more like a living system. It adapts. It grows with what you need.
This tutorial is my attempt to break down what I call "switches" in Notion - which is basically when you change one thing (usually a checkbox, status, or select property) and watch another part of your system automatically transform. Once you understand how switches work, you start seeing them everywhere in your workspace, and suddenly you're building systems that do exactly what you need without all the manual work.
Here's what I think is really powerful about Notion: you can log entries, summarize them to new databases, and display everything differently based on status - which gives you relevance and power without maintaining some nightmare of complexity.
There's this sweet spot between letting the software control your experience (because the system actually works) and having ultimate freedom to build what you need for the right moment.
Now, Notion gives us a lot of capabilities, but honestly? It can be restrictive at times. The next step beyond this is probably building your own software, or finding another tool that goes further - but those tools usually aren't as intuitive.
Notion blends the intuitive side of what you should have with almost all the customization you actually need. It gives you guardrails so you don't go off the deep end and make something that destroys what you're trying to create.
The makers of Notion have done their own software engineering and database design, so they know what works and what doesn't from experience. This is an easy, interactable experience - which is why I still promote the product as much as I do.
\nSwitches let you control what's relevant at any given moment. Instead of rigid folder structures or duplicate data everywhere, you get one source of truth with multiple ways to view and interact with it.
Before we get into the actual switches, let me clarify how they fit into Notion's bigger picture. I think this helps avoid confusion later.
Dynamic systems are Notion's overall capability where data edited in one place automatically updates everywhere else in your workspace. Change a database property, and that change shows up in every view, formula, and page that references it. This is the foundation that makes everything else possible.
\nFiltering is how you control what displays in a database view. You set criteria (like "Status is Active" or "Due Date is within 1 week") and only matching entries appear. Filters are static rules you configure - they don't change unless you manually edit them.
\nFormulas calculate and display dynamic information based on property values. Automations trigger actions when properties change, updating other properties automatically. Together, these are the outputs that respond to changes in your system - they make your workspace intelligent and reactive.
\nSwitches are properties you actively change that trigger all of the above to respond. A switch controls filtering (what displays), formulas (what calculates), and automations (what updates automatically). Switches make your dynamic system respond to your immediate needs by controlling what's relevant right now.
Think of it this way:
Traditional file systems like OneNote force you to manually organize folders and files. Files stay in one place, and you're constantly navigating between folders looking for things.
With Notion's database approach combined with switches, when you edit something in one place, it edits everywhere in your system. More importantly, switches let you control what subset of that information is relevant at any given moment without losing the full dataset.
The data stays the same. Only what you see changes.
You're not moving or copying data. You're controlling which subset is visible at any given moment through intelligent switches.
\nSwitches work in a simple framework: you change an INPUT property, which triggers a change in OUTPUT displays.
INPUT SWITCHES (what you change):
OUTPUT SWITCHES (what changes in response):
The power comes from combining different inputs with different outputs. A status property can trigger all three outputs simultaneously - filtering views, changing formula results, and launching automations.
Alright, let's talk about the properties you actively change to control your system. I'm going to walk through the main types and when to actually use each one - because honestly, choosing the wrong property type is one of the most common mistakes I see.
Why Checkboxes Matter for Switches
The checkbox is the simplest and fastest switch in Notion. It's binary: unchecked or checked, no or yes, false or true.
Here's why this matters: checkboxes require only one click to activate. No dropdown menus, no selecting from options - just immediate action. This speed makes checkboxes essential for rapid filtering, quick toggles, and situations where you're moving fast through your workflow.
The power of immediate action cannot be overstated. When you're triaging tasks during a meeting, flagging urgent items, or marking things complete, that single-click checkbox is the difference between fluid workflow and friction.
The Definition: Binary Control
A checkbox represents boolean logic - true or false, yes or no, on or off. This simplicity is its strength. There's no ambiguity, no in-between state, no decision paralysis. You check it or you don't.
In switch terminology, checkboxes are your rapid-fire controls. They're the light switches of your Notion workspace - immediate, clear, and require zero thought to operate.
In switch terminology, checkboxes are your rapid-fire controls. They're the light switches of your Notion workspace - immediate, clear, and require zero thought to operate.
Property Type: Checkbox (Boolean)
States: Two (checked/unchecked)
Best for: Immediate one-click actions
Speed: Instant (fastest switch type)
\nUse checkboxes when you need:
Why use a checkbox instead of a status?
Checkbox: Single click = immediate action. You click once and the switch activates instantly.
Status: Click + choose option = two-step process. You click to open the menu, then select which option you want.
When you need something to happen immediately with one click, use a checkbox. When you want defined text labels or emoji representations with multiple workflow stages, use a status.
\nDon't use checkboxes when:
Real-World Example: Urgent Flag System
In my task management system, I use a checkbox for "Urgent" instead of a status property. When something becomes urgent during a meeting or call, I need to flag it immediately with one click - not click to open a menu, then select "Urgent" from options.
The checkbox lets me instantly filter to show only urgent items in my daily view. If I used a status, the two-step process would slow down my workflow when I'm moving quickly through tasks.
The status property is probably the most common and most powerful type of switch you'll use. This is where you create properties that move from "To Do" to "In Progress" to "Done".
The Real Power: Default Values
Here's the most important reason to use status properties: status properties can automatically assign a default value when you create a new entry.
When you create a new task in your database, you can have it automatically set to "Not Started" or "To Do" without any manual input. This is huge for maintaining consistency across your system, especially when working with templates or quick captures.
Select properties don't have this capability - they start empty by default. If you need automatic default values, status properties are the only choice.
Property Type: Status
States: Multiple (grouped into To Do, In Progress, Done)
Best for: Workflow progression and multi-stage processes
Flexibility: High (unlimited custom options)
\nUse status properties when you need:
The status property looks similar to the select property - both let you choose one option from multiple text options.
The key differences:
Don't use status properties when:
The Three-State System
Notion's status properties are built around a three-state workflow model. Every status property organizes its options into three groups:
You can create as many custom status options as you need within these three groups. For example, your "To Do" group might contain "Not Started," "Backlog," and "Waiting," while your "In Progress" group might have "Active," "In Review," and "Testing."
Why the Three-State System Matters
The grouping structure helps Notion understand workflow progression. Board views automatically use these groups to organize columns. Automations can trigger based on group changes (like "when moved to Done"). The visual organization makes it immediately clear where something is in your workflow
Real-World Example: Multiple Status Switches
In my workspace, I use status properties for multiple switch types:
Text properties can work as switches when you need maximum flexibility or are working with complex technical requirements.
Why Text Properties Can Be Switches
Unlike status or select properties with predefined options, text properties accept any value. This makes them useful for dynamic switching scenarios where values are generated programmatically or need to integrate with external systems.
Unlike status or select properties with predefined options, text properties accept any value. This makes them useful for dynamic switching scenarios where values are generated programmatically or need to integrate with external systems.
Property Type: Text
States: Unlimited (any text value)
Best for: Technical edge cases and system integration
Flexibility: Maximum (no predefined options)
\nUse text properties as switches when you need:
Why status and checkbox are usually better:
Bottom line: Text properties are valid switches when their flexibility solves a specific technical problem that status or select cannot handle. For everyday manual switching, stick with status or checkbox.
\nThe properties below CAN work similarly to switches in dynamic systems, and you can filter by them, use them in formulas, and trigger automations when they change.
However, they serve bigger purposes than just switching - they're fundamental to how you structure and organize information in Notion. Their primary purpose isn't switching; it's assignment and data architecture.
For dedicated switching functionality, use status, checkbox, or (when justified) text properties.
\nA note on button properties: Technically, button properties are an input - you click them to trigger actions. However, they're really just a physical interface for automation switches, so we treat them as part of the automation output system rather than a separate input type.
Select properties look similar to status properties - both offer dropdown selection from multiple options. But select is designed for static categorization and tagging, not workflow switching.
Why Not Use Select for Switches?
Use select properties for:
If you're building a switch system, use status properties instead. Select can work in dynamic systems, but it's missing the key features (defaults, workflow groups) that make status properties ideal for switching.
\nPerson properties are for assigning responsibility and tracking ownership. When you assign someone to a task, you're designating who owns that work - not flipping a switch.
Why Person Properties Aren't Really Switches:
You can use person properties in dynamic systems:
Switching: Changing status from "To Do" to "Done" (state change)
Assignment: Changing person from John to Sarah (ownership change)
Both work in dynamic systems, but switching is about workflow state, assignment is about responsibility.
\nRelation properties build connections between databases. When you relate a task to a project, you're establishing a data relationship - not controlling what displays.
Why Relation Properties Aren't Really Switches:
You can use relation properties in dynamic systems:
Switching: Changing status to control visibility (workflow control)
Relating: Connecting task to project (data organization)
Relations enable filtering and dynamic behavior, but their main job is structuring your database architecture.
\nThe following property types CAN technically be read by formulas or automations, but are not recommended as manual input switches:
Now we get to the fun part - what actually happens when you flip a switch. I'm going to start with the simplest applications and build up to the more complex stuff progressively.
This is the simplest and most common use case for switches, and honestly, it's probably where you should start if you're new to this. When you change a property value, different views show or hide entries based on filters.
When you change a property value, different views show or hide entries based on filters.
Output Type: View Filtering
Complexity: Beginner-friendly
Best for: Organizing and decluttering databases
Requirements: None (works in all Notion plans)
\nUse view switching when you need:
The Fundamental Concept
You have one database with all your data. You create multiple views of that same database, each with different filters. When you change a switch property, entries appear in some views and disappear from others.
The data stays the same. Only what you see changes.
You're not moving or copying data. You're controlling which subset is visible at any given moment.
\nDon't use view switching when:
Simple Example: Show/Hide Completed Tasks
Let's start with the most basic switch setup:
When you check a task as done, it instantly disappears from Active Tasks and appears in Completed Tasks. You didn't move anything - the filter did all the work.
Now let's add more options with a status property:
Change the status property, and projects automatically move between views.
I use status switches to control what appears in my project views:
The same projects exist in the database, but I see completely different subsets based on which view I'm in.
\nAdding Context-Aware Properties
Here's where view switching gets more powerful: you can show different properties in different views based on what's relevant.
In my task system:
The switch (changing status to "Done") not only moves the task between views, but also changes what information displays because each view is configured differently.
Once you understand view switching, the next level is using switches to change what formulas calculate. The same formula property shows different results based on switch states.
The same formula property shows different results based on switch states.
Output Type: Formula Calculations
Complexity: Intermediate
Best for: Dynamic data displays and context-aware calculations
Requirements: None (works in all Notion plans)
\nUse formula switching when you need:
Don't use formula switching when:
This is where things start getting really interesting - and honestly, once you understand this, you can build some incredibly sophisticated systems.
Starting Simple: Basic IF Statements
Let's begin with a straightforward formula that responds to a checkbox:
if(prop("Urgent"), "π₯ HIGH PRIORITY", "Normal")This formula checks the "Urgent" checkbox. When checked, it displays "π₯ HIGH PRIORITY". When unchecked, it displays "Normal". The switch (Urgent checkbox) changes what the formula outputs.
Building on That: Multiple Conditions
Now let's add a status property into the mix:
if(prop("Status") == "Active", "Working on this now",
if(prop("Status") == "Planning", "Not started yet",
"Something else"))The formula checks the Status property and outputs different text based on which status is selected. Change the status (flip the switch), and the formula result changes.
Here's a practical example. You have a checkbox called "Show Today Only":
if(prop("Show Today Only"),
dateBetween(now(), prop("Due Date"), "days"),
dateBetween(now(), prop("Start Date"), "days"))When the checkbox is checked, the formula shows days until due date (relevant for active tasks).
When the checkbox is unchecked, the formula shows days since start date (relevant for tracking overall progress).
Same formula property, different calculations, controlled by a simple checkbox switch.
The formula doesn't change. The formula result changes based on the switch value.
This means you can have one formula property that serves multiple purposes depending on context.
\nNow let's get more sophisticated. You want to switch between showing different time tracking metrics:
if(prop("Display Mode") == "Sessions", prop("Session Time"),
if(prop("Display Mode") == "Estimates", prop("Estimated Time"),
prop("Goal Time")))You have a status property called "Display Mode" with three options: Sessions, Estimates, Goals.
The formula checks which option is selected and displays the corresponding time property. One switch, three different data points displayed.
I have three elements for tracking:
I use a switch to flip between what's relevant right now instead of having sessions, estimates, and goals all showing simultaneously.
Examples of what I can toggle:
Once your formulas get complex with multiple conditions, you'll want to use LETs to keep them organized.
Here's the same time tracking formula using LETs:
let(
mode, prop("Display Mode"),
sessions, prop("Session Time"),
estimates, prop("Estimated Time"),
goals, prop("Goal Time"),
if(mode == "Sessions", sessions,
if(mode == "Estimates", estimates, goals))
)The LETs formula lets you:
This becomes essential when you're checking multiple switch properties and calculating different results based on various combinations.
Formula Switching Philosophy
The key insight: formulas let switches control not just what you see, but what gets calculated. This transforms switches from simple show/hide tools into dynamic information processors.
This is the most advanced application - using switches to trigger automations that change other properties automatically. This goes beyond filtering views or calculating formulas. Automations actually modify your data.
Automations actually modify your data.
Output Type: Automated Property Changes
Complexity: Advanced
Best for: Workflow automation and cascading updates
Requirements: Notion Plus plan or higher ($10/month annually)
\nUse automation switching when you need:
To access database automations, you need the Notion Plus plan or higher ($10/month annually).
Why automations are different: Formulas calculate and display information. Automations actually change property values. This distinction is crucial for how you build your systems.
\nDon't use automation switching when:
Simple Automation: Two Inputs, One Output
Let's start with the clearest automation example: the Eisenhower Priority Matrix.
You have two checkbox switches:
You want a "Priority" select property to update automatically based on those two checkboxes.
The automation triggers when: Either checkbox changes
The automation action: Set Priority based on combination:
You could write this as a formula, but the automation actually changes the Priority property itself. This means:
Formulas: Calculate and display results, but don't change actual property values
Automations: Change the actual property values, which triggers other system behaviors
Use automations when you need the changed value to trigger something else (another automation, integration, or manual workflow).
\nIntermediate: Conditional Property Updates
Let's build on that. You want page names to update automatically, but only when preparing invoices.
Setup:
Automation 1: When Status changes to "Preparing Invoice" β Check "Show Time in Name"
Automation 2: When "Show Time in Name" is checked β Add time tracking info to page name
This creates a two-step automation chain where the status switch triggers a checkbox switch, which triggers the actual page update. You control when the complexity activates.
Advanced: Multi-Property Cascading Updates
Here's where automations become powerful for complex workflows.
When a project Status changes to "Complete":
One switch (Status β Complete) triggers a cascade of property changes that automate your entire completion workflow.
A Note on Button Properties
Technically, button properties are an input - you click them to trigger actions. However, they're really just a physical interface for automation switches. A button executes pre-configured automation logic with one click, so we're treating them as part of the automation output system rather than a separate input type.
Automation Strategy
The key to good automation switching:
Automations are powerful, but they can make your system harder to understand if overused. Use them for repetitive multi-step processes where manual work would be tedious.
Each example below demonstrates a specific switching concept, progressing from simple to advanced implementations.
Demonstrates: Pure view grouping and sorting with status property for visual organization
This is the clearest example of database view switching at its most fundamental - using a status property purely to control how entries are visually organized within a single view through grouping, without any formulas or automations.
How It Works:
The "Pin [A]" status property controls where tasks appear in my main view by using Notion's native grouping feature. The view groups by Pin [A] status and hides empty groups.
This is view switching in its purest form - no formulas, no automations, just native Notion grouping. The Pin status property simply controls visual organization through the view's group-by feature.
\nDemonstrates: Pure database filtering with checkbox switches - the foundational view switching pattern
This is the most basic switch pattern - one checkbox property controlling visibility across two views through filtering alone. No formulas, no automations, just clean view-based switching.
How It Works:
I have a Tasks database with one checkbox property called "Done". I create two views:
When I check the "Done" checkbox, the task instantly disappears from Active Tasks and appears in Completed Tasks.
This is the foundational switch pattern. One input (checkbox) controls visibility across two views. Every more complex switch system builds on this basic pattern.
\nDemonstrates: Status property distinguishing urgency type rather than workflow state
This example shows how status properties can represent categorization that affects filtering behavior without being part of a workflow progression. The Hard/Soft distinction is about the nature of the deadline itself.
How It Works:
In my Actions List database, some are hard deadlines - external commitments that cannot be moved (client presentations, event dates, regulatory filings). Others are soft deadlines - internal targets that provide structure but can be adjusted if needed.
The "Hard Deadline?" status property creates a fundamental distinction that affects how I filter and prioritize work.
The Hard/Soft distinction changes filtering behavior without representing workflow progression. This switch categorizes the nature of the commitment, which fundamentally affects how you prioritize and filter.
\nDemonstrates: Automation-driven property updates based on multiple checkbox inputs
Two checkbox switches (Urgent + Important) automatically update a Priority property through automation. This shows how automations can combine multiple inputs into a single calculated output.
How It Works:
I have two checkboxes that trigger an automation to set a Priority select property:
Two simple checkbox inputs create four distinct priority categories through automation. The automation changes the actual Priority property (not a formula), so I can filter views by it and other automations can trigger based on it.
\nDemonstrates: Formula calculations for controlling gallery card content display
This example uses formulas to control what displays inside gallery cards - specifically the Main Entry text property and contextual information pulled from relation properties and formatted via concat.
How It Works:
The formulas use concat (via .map() and .join()) to extract names from various relation properties and format them into readable lists based on which switch options are selected.
Example Formula:
let(
showHide, prop("Show Hide"),
projects, prop("Projects").map(current.prop("Name")).join(", "),
if(showHide == "Show All",
"π Projects: " + projects + "...",
if(showHide == "Show Some",
"π " + projects,
""))
)Two independent status switches control different aspects of gallery card display. The formulas dynamically extract and format information from relation properties using concat, giving you complete control over what displays in each gallery card.
\nDemonstrates: Multiple independent switches for granular control with formula-generated output
Instead of one switch controlling TO/BCC, this system uses three separate status switches to give precise control over email recipient placement.
How It Works:
Three independent status switches each control exactly one email field. A formula reads all three switches and pulls the appropriate contact lists from related databases, then formats everything as ready-to-copy email recipients.
This is a formula property that opens your email client automatically when clicked. You can also use a button property that triggers an automation to send email directly from Notion.
Three independent switches provide maximum flexibility. Instead of trying to encode all TO/CC/BCC combinations into one property (18+ options), each field gets its own simple two-option switch.
\nDemonstrates: Text formula properties as switches for navigating deep relational complexity (4+ database layers)
When your database architecture goes 4+ layers deep with complex many-to-many relationships, text properties generated by formulas become essential navigation tools.
Why Text Properties Become Necessary:
Text properties flatten complex relational data into filterable, displayable values. These text strings become switches - you can filter by them, use them in further formulas, trigger automations, and display them to users who might not have permission to see underlying relations.
\nDemonstrates: Complex formula switching with multiple interacting properties and automations
One formula property dynamically shows different time metrics (Sessions, Estimates, Goals) based on a single status switch, with optional automation chains and multiple interacting properties.
How It Works:
I have three different time properties but only want to see one at a time depending on context. The formula uses LETs to organize complex conditional logic:
let(
mode, prop("Display Mode"),
sessions, prop("Session Time"),
estimates, prop("Estimated Time"),
goals, prop("Goal Time"),
if(mode == "Sessions",
format(sessions) + " hrs worked",
if(mode == "Estimates",
format(estimates) + " hrs estimated",
format(goals) + " hrs goal"))
)Enhanced with automations: Status changes can trigger cascading automation chains that update related properties, time calculations, and dashboard displays.
One status property switch controls what a formula calculates and displays. Instead of having three separate time properties cluttering my database view, I have one "Time Display" property that shows the relevant metric. The optional automation layer adds even more dynamic behavior.
\nDemonstrates: Most complex - backend collector system with robust formulas and dual independent switches
This is the most sophisticated switch system - two independent status switches working together with multiple supporting properties, rollups, and complex filtering logic to create a backend collector that manages workspace-wide visibility.
How It Works:
My Compiled Lists Wiki database tracks all databases and systems in my workspace. The two status switches work independently but complementarily:
These switches don't depend on each other, creating maximum filtering flexibility.
Two independent status switches create flexible visibility control without complex conditions. Instead of one switch with 6+ options trying to encode all combinations, each switch handles one dimension of visibility. This separation means simpler option sets, flexible combinations, independent updates, and easier filtering.
\nDefault to Status for most switches - it has the functionality of multiple property types and can be as complex or simple as you need.
Use Checkboxes when you need immediate one-click action without choosing from options.
Avoid Multi-Select for switches - they become cumbersome with filtering. Use AND statements with separate properties instead.
\nWhen building database views, use the Advanced Filter instead of regular filters - it's easier to track ANDs and ORs.
Don't create 100-200 properties. Most overly complex systems come from unnecessarily complicated filtering. Keep it simple.
\nMaster LETs first before building complex switch formulas. The variable system makes formulas readable and maintainable.
Start simple with basic IF statements. Build complexity gradually. If you get stuck, step back and simplify.
Learn CONCAT for combining text elements - it works smoothly with LETs for dynamic displays.
\nYour switch system should make finding information easier, not harder.
You want it to be like finding a light switch - there it is, click, you get what you need. Not a puzzle to solve every time you want information.
If you find yourself confused about which switch does what, simplify immediately.
\nSwitches in Notion are one of the more complex features - along with metadata, relations, formulas, and rollups - that I consider integral to actually using Notion effectively.
There are many other cases you can use switches for, and you can make them as complex as you want. But remember:
Start with status properties and checkboxes
Master the LETs formula before getting fancy
Keep it simple - your system shouldn't be a puzzle
Use database views creatively with Advanced Filters
Think about what's relevant in the moment
Let automations do the heavy lifting when possible
With switches, you're not just organizing information - you're creating a workspace that adapts to you, showing you exactly what you need, when you need it.
That's the true power of a dynamic system controlled by intelligent switches.
\n