Switches in Notion
Details
Page Content
Table of Contents The Philosophy: Creating Actionable SystemsUnderstanding Switches vs. Filtering vs. Dynamic SystemsThe Switch Framework: Inputs and OutputsPart 1: Input SwitchesPart 2: Output SwitchesReal-World Switch Applications from My WorkspaceKey Principles for Building Switch SystemsConclusion 📖
About This Resource
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.
I'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.
The Philosophy: Creating Actionable Systems
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.
💡
Why Notion Gets It Right
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.
Switches 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.
Understanding Switches vs. Filtering vs. Dynamic Systems
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
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.
💡
Filtering
Filtering 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.
💡
Formulas & Automations
Formulas 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.
💡
Switches: The Bridge Between Them
Switches 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:
• Dynamic systems = the infrastructure • Filtering = the display rules • Formulas & Automations = the outputs that respond • Switches = the controls that activate everything
Why Switches Matter
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 Core Principle
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.
The Switch Framework: Inputs and Outputs
Switches work in a simple framework: you change an INPUT property, which triggers a change in OUTPUT displays.
💡
The Two-Part Switch System
INPUT SWITCHES (what you change):
• Checkbox properties • Status properties • Select properties • Text properties OUTPUT SWITCHES (what changes in response):
• Database view filtering • Formula calculations • Automations
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.
Part 1: Input Switches
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.
Checkbox Switches: The Binary Foundation
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.
💡
Examples Using Checkbox Switches
• Example 2: Simple To-Do List System - Uses "Done" checkbox for basic task completion filtering • Example 4: Priority Management System (Eisenhower Matrix) - Uses "Urgent" and "Important" checkboxes as automation inputs
💡
At a Glance
Property Type: Checkbox (Boolean)
States: Two (checked/unchecked)
Best for: Immediate one-click actions
Speed: Instant (fastest switch type)
💡
When to Use Checkboxes
Use checkboxes when you need:
• Immediate filtering - Instantly show/hide items with one click • Quick toggles - Turn features on/off without menus • Speed-critical switches - When two-step status selection slows you down • Simple automations - On/off triggers for automated workflows • Universal boolean logic - Simple true/false conditions in formulas
💡
The Critical Difference: Checkbox vs Status
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.
💡
Common Pitfalls
Don't use checkboxes when:
• You need more than two states (use status instead) • You want descriptive labels visible in the database • You need to track workflow progression through stages • Multiple team members need to understand the meaning at a glance
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.
Status Properties: The Workflow Engine
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.
💡
Examples Using Status Properties
• Example 1: Pin Priority Organization System - Uses "Pin [A]" status for visual grouping • Example 3: Hard Deadline vs. Soft Deadline System - Uses status for categorical distinction • Example 5: Writing Log Gallery Display - Uses "Recent Entry Switch" and "Show Hide" status properties for gallery card content • Example 6: Email Draft Composer System - Uses three separate status properties for TO/CC/BCC control • Example 7: Time Tracking Display System - Uses "Display Mode" status to switch between Sessions/Estimates/Goals • Example 8: Music Parts Distribution System - Uses "Status" and "Original or Mark Up?" status properties for workflow control • Example 9: Wiki Visibility Control System - Uses two status properties (Hide/Show + Deadline Switch)
💡
At a Glance
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)
💡
When to Use Status Properties
Use status properties when you need:
• Default values - Automatic assignment when creating new entries (THE killer feature) • Workflow progression - Move items through multiple stages • Visual workflow tracking - Color-coded stages with emoji • Team collaboration - Clear labels everyone understands • Multiple switch types - Pin, Remove, Hide/Show, Archive states • Most switch needs - Status is the default choice for 80% of switches
💡
Status vs. Select: Understanding the Difference
The status property looks similar to the select property - both let you choose one option from multiple text options.
The key differences:
• A status can have a default automatically (select cannot) • The status itself is meant to move through different workflow stages • Status properties have three built-in states: To Do, In Progress, Done • The select property is designed more for tagging and categorization rather than changing workflow states
💡
Common Pitfalls
Don't use status properties when:
• Simple on/off is all you need (use checkbox for speed) • You need the option to start truly empty with no default • The workflow doesn't actually progress through stages • You're creating 20+ status options (simplify your categories)
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:
• To Do - Items that haven't been started • In Progress - Items currently being worked on • Done - Items that are completed 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:
• Pin Status - Move high-priority items to the top • Remove - Hide items from certain views • Hide or Show - Control visibility in different contexts • Show in another page - Control where items appear across the workspace • Add more info to text properties - Trigger additional information display • Filter information in a formula - Change what formulas calculate and display • Filter information in a formula - Change what formulas calculate and display Text Properties: The Flexible Switch
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.
💡
Examples Using Text Properties
• Example 8: Music Parts Distribution System - Uses text formulas ("Current Semester," "Group (Instrument)," "Next Date Info") to navigate 4+ database layers and create filterable switches
💡
At a Glance
Property Type: Text
States: Unlimited (any text value)
Best for: Technical edge cases and system integration
Flexibility: Maximum (no predefined options)
💡
When Text Properties Work as Switches
Use text properties as switches when you need:
• Complex rollup chains - Nested rollups where status/select create cascading issues • External system integration - API or CSV compatibility requires plain text • Dynamic value generation - Switch values calculated by formulas or automations • Template variable systems - Values need text concatenation or replacement • Maximum flexibility - Situations where predefined options are too restrictive • The automation fail-safe - When formulas don't work due to permissions: use automations to copy status or formula values into text properties, making them accessible to guests and users with limited permissions (like Notion site access)
💡
Limitations to Consider
Why status and checkbox are usually better:
• Text requires manual typing (typos break filtering) • No dropdown selection (slower, less user-friendly) • No visual indicators (harder to scan at a glance) • No default values (like select properties) • Team members can enter inconsistent values 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.
Properties That Work Like Switches (But Serve Bigger Purposes)
💡
Important Context
The 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.
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, so we treat them as part of the automation output system rather than a separate input type. Select Properties: Static Categorization
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?
• No default values - Select always starts empty, breaking consistency • No workflow structure - Select has flat options, not grouped states • No progression signal - Select indicates categories, not movement through stages • Status does everything select does PLUS more - Status has all the same filtering and formula capabilities with better switching features 💡
When Select Makes Sense (Not as a Switch)
Use select properties for:
• Static tags - Department, Category, Type labels • Non-workflow classification - Genre, Priority Level, Client Type • When empty is meaningful - Some entries genuinely have no category
💡
The Bottom Line
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.
Person Properties: Assignment and Ownership
Person 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:
• Primary purpose is assignment - Tracking who's responsible for what • Changes represent reassignment - Not state progression • Organizational tool - About people and ownership, not workflow states • No on/off state - Just different people assigned (or unassigned) 💡
What Person Properties DO Enable
You can use person properties in dynamic systems:
• Filter views by who's assigned • Trigger automations when specific people are assigned • Use formulas to display different info based on assignment • Create personalized dashboards per team member
💡
The Distinction
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.
Relation Properties: Data Architecture
Relation 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:
• Primary purpose is connection - Linking related data across databases • Changes represent re-linking - Not state progression • Architectural tool - About organizing hierarchical data structures • Complex setup - Requires maintaining multiple databases 💡
What Relation Properties DO Enable
You can use relation properties in dynamic systems:
• Filter views by related items (show tasks for Project X) • Use formulas to pull data from related entries • Trigger automations when items are linked • Switch contexts by changing relations
💡
The Distinction
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.
Other Properties: Not Recommended
The following property types CAN technically be read by formulas or automations, but are not recommended as manual input switches:
💡
Examples Using URL, Email, Phone Properties
• Example 6: Email Draft Composer System - Extracts Email properties from related pages (Teaching Studios and contacts databases) using formulas to build recipient lists
• URL, Email, Phone: Similar limitations to text properties (manual typing, no dropdowns, typo-prone) • File & Media: Not practical as switches - files are for content storage, not control logic • Created Time / Last Edited Time: Automatic timestamps can't be manually changed for switching • Created By / Last Edited By: Automatic user tracking, similar functionality to Person but not manually controllable • Formula: This is an OUTPUT type, not an input - formulas calculate, they don't switch • Rollup: This is an OUTPUT type - rollups aggregate data from relations • Auto-increment ID: Automatically assigned numbers, not suitable for manual switching
Part 2: Output Switches
💡
Examples Demonstrating View Switching
• Example 1: Pin Priority Organization System - Pure view grouping with status property for visual organization • Example 2: Simple To-Do List System - The foundational pattern showing pure database filtering with checkbox 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.
Output Type 1: Database View Switching
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.
💡
At a Glance
Output Type: View Filtering
Complexity: Beginner-friendly
Best for: Organizing and decluttering databases
Requirements: None (works in all Notion plans)
💡
When to Use View Switching
Use view switching when you need:
• Clean workspaces - Hide completed or archived items • Context-based displays - Show different subsets for different purposes • Team views - Create personalized views for different roles • Status-based organization - Separate items by workflow stage • Simple filtering - Basic show/hide without calculations
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 Core Principle
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.
💡
Common Pitfalls
Don't use view switching when:
• You need calculated values (use formulas instead) • You need automated property changes (use automations instead) • You're creating 20+ views (simplify your system) • Filters are overly complex with many nested conditions (reconsider your structure)
Simple Example: Show/Hide Completed Tasks
Let's start with the most basic switch setup:
• You have a Tasks database • Each task has a checkbox property called "Done" • You create two views:Active Tasks view: Filter shows only tasks where Done is unchecked • Completed Tasks view: Filter shows only tasks where Done is checked 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.
Slightly More Complex: Status-Based Views
Now let's add more options with a status property:
• You have a Projects database • Each project has a Status property: "Planning," "Active," "On Hold," "Completed" • You create multiple views:Current Work view: Filter shows Status = Active • Waiting view: Filter shows Status = On Hold • Archive view: Filter shows Status = Completed Change the status property, and projects automatically move between views.
💡
Practical Example: My Project Filtering System
I use status switches to control what appears in my project views:
• Active view: Only shows projects with "Active" or "In Progress" status • Pinned view: Only shows projects where the PIN checkbox is checked • Archive view: Shows projects marked "Remove" or "Completed" The same projects exist in the database, but I see completely different subsets based on which view I'm in.
Adding 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:
• Active view shows: Task name, Due date, Person assigned • Completed view shows: Task name, Date completed, Time spent 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.
Output Type 2: Formula Switches
💡
Examples Demonstrating Formula Switches
• Example 5: Writing Log Gallery Display - Formula calculations controlling gallery card content display • Example 6: Email Draft Composer System - Multiple status switches controlling email recipient formula output • Example 7: Time Tracking Display System - Status property switching between different time metrics in one formula • Example 8: Music Parts Distribution System - Text formula properties navigating deep relational complexity
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.
💡
At a Glance
Output Type: Formula Calculations
Complexity: Intermediate
Best for: Dynamic data displays and context-aware calculations
Requirements: None (works in all Notion plans)
💡
When to Use Formula Switches
Use formula switching when you need:
• Dynamic calculations - Different formulas for different contexts • Multi-purpose properties - One property that shows different data • Conditional displays - Show different information based on state • Complex logic - IF statements driven by switch values • Data transformation - Format or calculate based on mode
💡
Common Pitfalls
Don't use formula switching when:
• You need to change actual property values (use automations) • Other automations need to trigger based on the result (use automations) • The formula becomes unreadable (simplify or split into multiple properties) • You're nesting 5+ levels of IF statements (reconsider your approach)
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.
Making It Useful: Time-Based Display
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.
💡
How This Works
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.
Intermediate Level: Switching Between Data Type
Now 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.
💡
Real-World Example: My Time Tracking System
I have three elements for tracking:
• Sessions are me working in the moment • Estimates means how long it's actually going to take to finish • Goal is the total amount of time I want to spend 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:
• Today's progress vs. full length progress • Time remaining today vs. time remaining for the full goal • Current session time vs. total time across all sessions
Advanced Level: The LETs Formula System
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:
• Define variables at the start (mode, sessions, estimates, goals) • Reference those variables in your logic • Make complex formulas much easier to read and maintain 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.
Output Type 3: Automation Switches
💡
Examples Demonstrating Automation Switches
• Example 4: Priority Management System (Eisenhower Matrix) - Two checkbox inputs triggering automation to set Priority property
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.
💡
At a Glance
Output Type: Automated Property Changes
Complexity: Advanced
Best for: Workflow automation and cascading updates
Requirements: Notion Plus plan or higher ($10/month annually)
💡
When to Use Automation Switches
Use automation switching when you need:
• Cascading updates - One change triggers multiple property updates • Workflow automation - Automate repetitive multi-step processes • Integration triggers - Changed values that external tools can read • Complex dependencies - Multiple properties that stay in sync • Batch operations - One switch updates many properties at once
💡
Requirements & Important Note
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.
💡
Common Pitfalls
Don't use automation switching when:
• Formulas would work just as well (automations add complexity) • You're creating circular automation loops (causes errors) • The logic isn't documented (you'll forget how it works) • You haven't tested thoroughly (automations change actual data) • Simple manual updates are faster (not everything needs automation)
Simple Automation: Two Inputs, One Output
Let's start with the clearest automation example: the Eisenhower Priority Matrix.
You have two checkbox switches:
• "Urgent" (checkbox) • "Important" (checkbox) 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:
• Urgent ✓ + Important ✓ → Priority = "Do Now" • Not Urgent + Important ✓ → Priority = "Schedule" • Urgent ✓ + Not Important → Priority = "Delegate" • Not Urgent + Not Important → Priority = "Delete" You could write this as a formula, but the automation actually changes the Priority property itself. This means:
• You can filter by the Priority value directly (not formula results) • Other automations can trigger based on Priority changes • External integrations can read the actual property value 💡
Why Use Automations Instead of Formulas?
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).
Intermediate: Conditional Property Updates
Let's build on that. You want page names to update automatically, but only when preparing invoices.
Setup:
• Status property: "Active," "Preparing Invoice," "Complete" • Checkbox: "Show Time in Name" 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":
• Automation checks "Done" checkbox • Automation sets "Date Completed" to today • Automation updates "Archive Status" to "Ready" • That status change triggers another automation that moves it to archive view 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:
• Start simple with single-trigger, single-action automations • Test thoroughly before adding complexity • Document your automation chains so you remember what triggers what • Use automation switching sparingly - not everything needs to be automated 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.
Real-World Switch Applications from My Workspace
Each example below demonstrates a specific switching concept, progressing from simple to advanced implementations.
Example 1: Pin Priority Organization System 📌
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.
💡 Input Switches: • Status property: "Pin [A]" with options: "📍" (high priority), "📌" (standard priority), or empty/unmarked
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.
💡 Output Switches: • Database view grouping (visual organization by pin status) • View sorting (within each group, sorted by date and urgency)
💡 Why This Works: 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.
💡
Related Systems & Implementations
• Content Production Pipeline - Pin articles/videos currently in production to top of editorial calendar • Customer Support Queue - Pin escalated tickets to surface them above standard queue • Email Inbox Database - Pin emails requiring response today, standard pin for this week • Reading List - Pin books/articles actively reading, standard pin for "read next" • Meeting Agenda Builder - Pin critical discussion topics to ensure they're addressed first
Example 2: Simple To-Do List System ✅
Demonstrates: 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.
💡 Input Switches: • Checkbox property: "Done"
How It Works:
I have a Tasks database with one checkbox property called "Done". I create two views:
• Active Tasks view: Filter shows only tasks where Done is unchecked • Completed Tasks view: Filter shows only tasks where Done is checked When I check the "Done" checkbox, the task instantly disappears from Active Tasks and appears in Completed Tasks.
💡 Output Switches: • Database view filtering (2 views)
💡 Why This Works: This is the foundational switch pattern. One input (checkbox) controls visibility across two views. Every more complex switch system builds on this basic pattern.
💡
Related Systems & Implementations
• Habit Tracker - "Completed Today" checkbox filters daily habit dashboard from full habit history • Inventory Management - "In Stock" checkbox separates available items from items needing reorder • Reading List - "Read" checkbox moves books from current reading list to completed archive • Content Publishing - "Published" checkbox filters draft content from live published content • Subscription Management - "Active" checkbox separates current subscriptions from cancelled ones
Example 3: Hard Deadline vs. Soft Deadline System ⏰
Demonstrates: 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.
💡 Input Switches: • Status property: "Hard Deadline?" with options: "⭕Hard" (non-negotiable deadline), "🔵Soft" (flexible target date)
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.
💡 Output Switches: • Database view filtering (separate views for hard vs. soft deadlines) • Sorting priority (hard deadlines sort before soft deadlines at same date)
💡 Why This Works: 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.
💡
Related Systems & Implementations
• Expense Tracking - "Billable" vs "Non-Billable" status controlling which expenses appear in client invoices • Bug Database - "Regression" vs "New Bug" status distinguishing previously working features • Customer Support Tickets - "Paying Customer" vs "Free Tier" status affecting priority queues • Content Pipeline - "Evergreen" vs "Time-Sensitive" status controlling scheduling flexibility • Inventory Management - "Perishable" vs "Shelf-Stable" status affecting reorder timing
Example 4: Priority Management System (Eisenhower Matrix) 🎯
Demonstrates: 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.
💡 Input Switches: • Checkbox property: "Urgent" • Checkbox property: "Important"
How It Works:
I have two checkboxes that trigger an automation to set a Priority select property:
• Urgent ✓ + Important ✓ → Priority = "Do Now" • Not Urgent + Important ✓ → Priority = "Schedule" • Urgent ✓ + Not Important → Priority = "Delegate" • Not Urgent + Not Important → Priority = "Delete" 💡 Output Switches: • Automation (updates Priority select property) • Database view filtering (4 views based on Priority)
💡 Why This Works: 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.
💡
Related Systems & Implementations
• Risk Assessment Matrix - "Likelihood" + "Impact" checkboxes → Auto-set Risk Level • Customer Segmentation - "High Value" + "High Engagement" checkboxes → Auto-categorize • Bug Triage System - "Severe" + "Frequent" checkboxes → Auto-prioritize • Feature Prioritization - "User Impact" + "Easy to Build" checkboxes → Auto-score • Lead Qualification - "Budget" + "Authority" checkboxes → Auto-classify
Example 5: Writing Log Gallery Display 📝
Demonstrates: 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.
💡 Input Switches: • Status Property: "Recent Entry Switch" (options: "Show Many Recent," "Show One Recent," "Hide Entries") • Status Property: "Show Hide" (options: "Show All," "Show Some," "Hide All")
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, ""))) 💡 Output Switches: • Formula calculation (Related Material Gallery property controls contextual info display) • Main Entry text property shown/hidden in gallery cards
💡 Why This Works: 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.
💡
Related Systems & Implementations
• Research Notes Gallery - Switch between showing full excerpts vs summaries via concat formulas • Product Backlog Cards - Control description length, toggle visibility of related epics/sprints • Customer Feedback Board - Switch between brief vs detailed feedback display • Content Calendar Cards - Toggle between showing full drafts vs headlines • Recipe Collection Gallery - Switch between full instructions vs ingredient lists
Example 6: Email Draft Composer System 📧
Demonstrates: 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.
💡 Input Switches: • Status Property: "(To) Send Email" (options: "Studio," "Contacts") • Status Property: "(CC) Send Email" (options: "Studio," "Contacts," "None") • Status Property: "(BCC) Send Email" (options: "Studio," "Contacts")
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.
💡 Output Switches: • Formula calculation (Email Contacts property) • Automation/Button (to send email via Notion)
💡 Why This Works: 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.
💡
Related Systems & Implementations
• Department Communication Router - Separate switches for TO/CC/BCC selecting from different teams • Document Distribution System - Independent switches for "Share With," "Notify," "Request Review From" • Meeting Invitation Composer - Separate controls for Required/Optional/FYI Recipients • Marketing Campaign Segmentation - Independent switches for Email List, SMS List, Ad Audience • Report Distribution System - Separate switches for Full Report/Summary/Dashboard Access
Example 7: Music Parts Distribution System 🎵
Demonstrates: 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.
💡 Input Switches: • Status Property: "Status" (options: "To-Do," "Scanning," "Ready!") • Status Property: "Original or Mark Up?" (options: "Original," "Mark Up")
💡 Text Formula Properties (that act as switches): • "Relate Instrument from PDF" → extracts: "Violin," "Trombone," etc. • "Group (Instrument)" → extracts: "Strings," "Brass," etc. • "Current Semester" → navigates 4 layers to extract: "Current," "Upcoming," "Past" • "Next Date Info" → combines multiple relations: "Feb 16, 2025 - Morning Service"
Why Text Properties Become Necessary:
• Nested rollups become unstable through 4+ layers • Formulas can't traverse bidirectional paths • Filter performance degrades with complex relations • Permissions break formula access for guests 💡 Output Switches: • Database view filtering (musician-specific views) • Conditional formatting based on text values • Further formula calculations using text switches
💡 Why This Works: 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.
💡
Related Systems & Implementations
• Dynamic Home Page System - Text formulas pull "Current/Upcoming/Past" from 4-layer publishing schedule • Event Management Platform - Navigate 4 layers to surface "Who can work this event" • Curriculum Planning System - Text formulas traverse layers to show "Teaching This Week/Quarter" • Multi-Location Inventory - Navigate layers to generate "In Transit/Arriving/In Stock" switches • Healthcare Appointment System - Text formulas through 4 layers to filter "Approved/Pending/Denied"
Example 8: Time Tracking Display System ⏱️
Demonstrates: 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.
💡 Input Switches: • Status property: "Display Mode" (options: "Sessions," "Estimates," "Goals") • Optional: Checkbox "Today Only" for additional switching layer
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.
💡 Output Switches: • Formula calculation (shows different time data) • Database view filtering (optional views for each mode) • Optional: Automations for cascading property updates
💡 Why This Works: 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.
💡
Related Systems & Implementations
• Workout Routine Tracker - Switch between Sets, Reps, Weight, Rest Time based on training focus • Financial Dashboard - Toggle between Revenue, Expenses, Profit Margin, Growth Rate • Study Session Tracker - Switch between Duration, Total Time, Daily Goals, Weekly Average • Content Performance Metrics - Toggle between Views, Engagement, Conversion, Revenue • Sales Pipeline Display - Switch between Deal Value, Days in Stage, Close Probability
Example 9: Wiki Visibility Control System 📚
Demonstrates: 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.
💡 Input Switches: • Status Property: "Hide/Show" (options: "Show All," "Show Some," "Hide All") • Status Property: "Deadline Switch" (options: "Today," "Week")
💡 Supporting Properties: • Status (status) - Workflow state: Inbox, Open, Stored • Core System? (checkbox) - Identifies essential databases • pin (status) - Pin high-priority items • Database Function (select) - Categorizes list types • Inbox (rollup) - Count of unprocessed items
How It Works:
My Compiled Lists Wiki database tracks all databases and systems in my workspace. The two status switches work independently but complementarily:
• Hide/Show determines if a list appears in general navigation views • Deadline Switch determines if a list appears in time-based work views These switches don't depend on each other, creating maximum filtering flexibility.
💡 Output Switches: • Database view filtering (multiple views based on switch combinations) • Navigation visibility (what appears in daily vs weekly planning pages) • Dashboard display (context-aware list surfacing)
💡 Why This Works: 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.
💡
Related Systems & Implementations
• Client Portal Pages - "Visibility" + "Update Frequency" switches controlling dashboard contexts • Resource Library - "Access Level" + "Content Type" switches creating flexible filtered views • Meeting Notes Archive - "Relevance" + "Confidentiality" switches controlling user contexts • Knowledge Base Articles - "Status" + "Audience" switches filtering documentation portals • Product Roadmap - "Priority" + "Visibility" switches for team vs customer-facing views
Key Principles for Building Switch Systems
💡
Choose Your Input Switches Wisely
Default 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.
💡
Keep View Filtering Simple
When 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.
💡
Formula Switching Strategy
Master 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.
💡
The Golden Rule
Your 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.
Conclusion
Switches 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
💡
The True Power of Switches
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.
SEO Blob
# Switches in Notion: The Tutorial for the Dynamic Workspace ## Overview This resource serves as a comprehensive guide for understanding and utilizing "switches" within Notion, designed to enhance productivity, organization, and dynamic workflows for users ranging from beginners to advanced practitioners. The tutorial highlights the powerful capabilities of Notion, focusing on its dynamic nature characterized by filters, formulas, automations, and templates. ## Key Features - Dynamic Nature: Notion evolves with user needs, allowing for real-time adjustments and modifications. - Switches: Modifying one element (e.g., a checkbox or status) triggers automatic updates in other parts of the system, facilitating seamless organization and workflow management. - Philosophy of Actionable Systems: Emphasizes the balance between control and flexibility, enabling users to create relevant and powerful systems without overwhelming complexity. ## Types of Switches - Input Switches: Checkbox, Status, Select, and Text properties that trigger changes. - Output Switches: Database view filtering, Formula calculations, and Automations that respond to input changes. ## Practical Applications - Checkboxes: Simple, binary controls for immediate actions. - Status Properties: Manage workflow progression, allowing for automatic default values and visual tracking. - Text Properties: Offer flexibility for complex scenarios and system integration. ## Advanced Techniques - Dynamic Systems: Explains how changes in one area update across the workspace. - Filtering and Formulas: Outlines how to use switches to control visibility and calculations dynamically. - Automations: Discusses how to set up cascaded updates triggered by switches. ## Examples and Use Cases - Pin Priority Organization: Visual organization through status properties. - Simple To-Do List: Filtering tasks based on completion status with checkboxes. - Priority Management System: Using automations for setting priorities based on urgency and importance. ## Accessibility Features - Designed to be user-friendly and intuitive, allowing users to adapt patterns to their specific needs. - Encourages creative use of database views and filters to maintain clarity and relevance in information management. ## Download and Usage This resource is currently in development and is projected for release in December 2025. Users interested in optimizing their Notion experience can expect detailed examples and in-depth explanations. --- This tutorial is essential for anyone looking to deepen their understanding of Notion and enhance their productivity through effective use of dynamic systems and switches. It is geared towards musicians, composers, and productivity enthusiasts, providing practical insights and methodologies for harnessing Notion's full potential.