Enhancement Proposal: Dynamic List Filters Based on the Logged-in User
One limitation we’ve seen in larger, multi-location applications is that list screen filters currently only support fixed values.
For example, today you can create a filter like:
- Store = Store A
- Status = Open
…but you can’t create a filter like:
Task.Store = Logged-in User.Store
Current Behavior
NotionApps already provides a few ways to personalize what users see, but each solves a different problem.
Data Restriction
Data Restriction allows you to match a database property to a user property.
For example:
Assigned User = Logged-in User
This works well for global security rules such as “My Tasks.”
However, each database supports only one Data Restriction, making it difficult to support multiple independent personalization scenarios.
Screen Visibility
Screen Visibility lets you show or hide entire screens based on the logged-in user.
This works well when different roles need completely different interfaces.
However, it does not filter the rows inside a list.
The Common Workaround
Imagine an application used by five different stores.
Each store should only see tasks for its own location.
Since list filters can’t reference Logged-in User → Store, builders typically end up doing something like this:
- Duplicate the same Tasks list screen five times.
- Hard-code a different filter on each screen.
- Store = Store A
- Store = Store B
- Store = Store C
- etc.
- Use Screen Visibility so each team only sees its own copy.
If that same Tasks database also uses Data Restriction for something like:
Assigned User = Logged-in User
there’s no remaining Data Restriction available for Store, so duplicating screens becomes the only practical solution.
Why This Becomes a Problem
As applications grow, this pattern creates unnecessary complexity.
Instead of maintaining one screen, builders end up maintaining many nearly identical copies.
That means:
- Every UI change has to be repeated multiple times.
- Applications accumulate unnecessary screens.
- Maintenance becomes increasingly time-consuming.
- Scaling to additional stores, departments, regions, or clients means creating even more duplicate screens.
Ultimately, the real requirement isn’t multiple screens.
It’s one shared screen with personalized results.
Proposed Enhancement
We’re exploring support for dynamic list filters that reference properties on the logged-in user.
For example:
Task.Store → equals → Logged-in User → Store
With this approach:
- One screen
- One configuration
- Personalized results for every user
How It Would Work Alongside Existing Features
Each feature would continue to have a distinct responsibility:
Data Restriction
Controls what data a user is allowed to access.
Think of this as your application’s security boundary.
Dynamic List Filters
(Proposed)
Controls what this particular list should display.
This becomes presentation logic rather than security logic.
Screen Visibility
Controls whether a user can access an entire screen.
Useful when different roles genuinely require different interfaces.
Example
Using the same five-store application:
Instead of maintaining five nearly identical screens, you would simply:
- Create a single Tasks list.
- Add a filter:
- Store
- equals
- Logged-in User → Store
- Continue using Data Restriction for global security rules (such as “My Tasks”) where appropriate.
- Every user opens the same screen and automatically sees only the rows for their store.
As your business grows from five stores to ten or twenty, the application grows with your data—not with duplicated screens.
Why This Matters
Multi-location and multi-team applications are one of the most common use cases for NotionApps.
Supporting user-based list filters would eliminate one of the biggest structural workarounds builders currently use and make applications significantly easier to design and maintain.
Instead of thinking:
“Which version of this screen should I show?”
builders could simply think:
“Show me the records that belong to me, my team, my store, or my client.”
We’d Love Your Feedback
Have you run into this limitation?
- Have you duplicated screens for stores, departments, regions, or clients?
- Would user-property list filters simplify your application?
- What scenarios would you like to support first?
- Store
- Region
- Department
- Client
- Team
- Role
- Something else?
Share your use cases below—they’ll help us prioritize this enhancement.