> For the complete documentation index, see [llms.txt](https://docs.notionapps.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.notionapps.com/guides/filter-list-screens-by-logged-in-user-properties.md).

# Filter List Screens by Logged-in User Properties

This guide is for **app makers** building in the NotionApps builder.

It explains how to make **one list screen** show different rows for different people — based on properties on their user profile — without duplicating the screen for every store, team, or location.

{% hint style="info" %}
**Availability: Pro and above**

Logged-in user property filters are available on **Pro**, **Premium**, and **Enterprise** subscriptions. They are **not** available on Free or Plus.
{% endhint %}

If you only remember one sentence:

> On a list’s **Filtering** section, you can set a filter value to **Logged-in user property** so `Tasks.Store` matches whatever Store is on the person who is currently logged in.

***

### Who this is for

Use this guide if you:

* Build or edit apps in the **builder**
* Have list screens (Tasks, Orders, Tickets, Restaurants, etc.)
* Want each employee to see **only their** rows on a shared list
* Are tired of cloning the same list once per store and wiring **Screen Visibility Logic** on every clone

You do **not** need this guide for:

* Hiding an entire screen from some roles (that is still **Screen Visibility Logic**)
* Letting end users change filters themselves in the live app (that is **In-App Filtering**)
* Database-wide access rules (that is **Data Restriction**, configured separately)

***

### The idea in plain language

Today, a normal list filter looks like this:

```
Show tasks where Store equals "North"
```

That value `"North"` is **fixed**. Everyone who opens the list sees North tasks only.

The new option lets you write:

```
Show tasks where Store equals (the Store on the logged-in user)
```

So:

* When **Alex** (Store = North) opens Tasks → Alex sees North tasks
* When **Jordan** (Store = South) opens the **same** Tasks screen → Jordan sees South tasks
* You maintain **one** screen instead of three

That is all this feature is: a smarter kind of filter value on a list.

***

### Full example: multi-store Tasks app

Walk through this example once. Everything else in the guide is the same pattern with different property names.

#### Your data

**Tasks** database:

| Task         | Store | Status |
| ------------ | ----- | ------ |
| Restock milk | North | Open   |
| Fix freezer  | South | Open   |
| Clean lobby  | East  | Open   |
| Count till   | North | Open   |

**Users** (employees who log into the app):

| Employee | Email                | Store |
| -------- | -------------------- | ----- |
| Alex     | <alex@company.com>   | North |
| Jordan   | <jordan@company.com> | South |
| Sam      | <sam@company.com>    | East  |

#### What you want

| Person | Opens | Should see               |
| ------ | ----- | ------------------------ |
| Alex   | Tasks | Restock milk, Count till |
| Jordan | Tasks | Fix freezer              |
| Sam    | Tasks | Clean lobby              |

#### The old way (what you can stop doing)

1. Duplicate Tasks → “North Tasks”, “South Tasks”, “East Tasks”
2. On North Tasks, set filter `Store equals North` (fixed value)
3. On North Tasks, set Screen Visibility so only North users can open it
4. Repeat for South and East
5. Hit screen limits as you add more stores

#### The new way (what this guide teaches)

1. Keep a **single** Tasks list
2. Turn on **Allow logged-in user property filters** for that list
3. In **Filtering**, set:\
   `Store` **equals** **Logged-in user property** → `Store`
4. Publish and test as Alex and Jordan

No per-store clones. No Screen Visibility rules for this pattern.

***

### Before you start (maker checklist)

#### 1. Your databases need matching properties

For the Tasks example to work:

1. The **Users** database (the people who log in) must have a property such as **Store**.
2. The **Tasks** database must have a property such as **Store**.
3. Those two properties should be the **same kind** of field:
   * both **Select** with the same options, or
   * both **Relation** pointing at the same Stores database\
     Mixing unrelated types (text vs relation, different option sets) usually gives empty or surprising results.

Rename freely in your app — the property does not have to be called “Store”. Common alternatives: Location, Team, Region, Branch, Department, Restaurant.

#### 2. Every user who should see rows needs that property filled in

If Alex’s Store is blank, Alex’s Tasks list will be **empty**.\
That is intentional safety behavior: the app will not “show everything” when it cannot tell which store Alex belongs to.

Before you test, open your Users data and confirm each test employee has Store set.

#### 3. Your subscription must be Pro or above

Logged-in user property filters require a **Pro**, **Premium**, or **Enterprise** plan. They are **not** included on Free or Plus.

In the builder, on a list screen, look for a section titled:

**Logged-in user property filters**

with a switch:

**Allow logged-in user property filters**

| What you see                                                                                                    | What it means                                                                                                                                                                                                            |
| --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Switch works; you can turn it On                                                                                | Your plan includes the feature — continue this guide                                                                                                                                                                     |
| Switch is disabled / locked, with a message that the feature is not available on your plan or has been disabled | Your plan is below Pro, or the feature has been disabled for this account/app. Upgrade to **Pro or above**, or ask your NotionApps admin/support contact to enable it. You cannot unlock this yourself from the builder. |

Until that switch can be turned on, stick with fixed-value filters (the classic behavior).

***

### Step-by-step: set up the Tasks example

#### Step 1 — Open the list screen

1. Open your application in the **builder**.
2. Select the **Tasks** list screen in the left navigation or preview (the one shared list — not a store-specific clone).
3. Keep the right-hand configuration panel open for that list.

You should be editing a **List** screen. Forms, detail pages, and visibility-only settings are the wrong place for this feature.

![Example: list selected in the builder](https://files.catbox.moe/l01f5i.png)

***

#### Step 2 — Allow logged-in user property filters on this list

On the Tasks list inspector, find:

**Logged-in user property filters**

1. Turn **Allow logged-in user property filters** **On**.

![Example: per-list toggle on](https://files.catbox.moe/yoc7el.png)

What this switch does:

| Setting | Effect                                                                        |
| ------- | ----------------------------------------------------------------------------- |
| **On**  | This list is allowed to use filter values of type **Logged-in user property** |
| **Off** | This list only allows classic **Fixed value** filters (same for every user)   |

Important details:

* This switch is **per list**. Turning it on for Tasks does not change Orders unless you do the same there.
* Turning the switch **On** alone does **not** filter anything yet. You still have to add a filter in the next step.
* Turning it **Off** later disables user-property filters on that list only (handy if you want to revert one screen without affecting others).

Help text on the section (paraphrased) explains that you can compare a list property to a property on the logged-in user’s profile — for example Store on the list equals Store on the user.

***

#### Step 3 — Open Filtering (not Screen Visibility)

Still on the Tasks list, open the **Filtering** section.

{% hint style="warning" %}
**Easy mistake**\
**Screen Visibility Logic** controls whether someone can open the screen at all.\
**Filtering** controls which rows appear once they are on the list.

This feature lives under **Filtering**.\
If you only edit Screen Visibility, you will never see the new “Logged-in user property” value type for list rows.
{% endhint %}

![Example: Filtering section](https://files.catbox.moe/tg7qfi.png)

Also do not confuse this with **In-App Filtering**:

| Section                     | Who configures it  | Who changes it while using the app                        |
| --------------------------- | ------------------ | --------------------------------------------------------- |
| **Filtering** (this guide)  | You, the maker     | Nobody — it is fixed by you (but can be dynamic per user) |
| **In-App Filtering**        | You enable columns | End users pick their own filter values                    |
| **Screen Visibility Logic** | You, the maker     | Nobody — hides or shows the whole screen                  |

***

#### Step 4 — Add the Store filter

1. Add a new filter condition (or edit an existing Store filter).
2. Set the left-hand property to **Store** from the **Tasks** database (the list’s data).
3. Set the operator to **equals** (or the closest match your UI offers).
4. Find the **value type** control for that filter row. You should now see two choices:

| Value type                  | Meaning                                                                        |
| --------------------------- | ------------------------------------------------------------------------------ |
| **Fixed value**             | You pick a specific Store (North, South, …). Same for every user.              |
| **Logged-in user property** | You pick a property from the **logged-in user’s** profile. Different per user. |

![Example: value type menu](https://files.catbox.moe/zly3jk.png)

5. Choose **Logged-in user property**.
6. When prompted for which user property, choose **Store** (the Store on the user profile — not a fixed “North” option).

You have now said:

```
Tasks.Store  equals  Logged-in user’s Store
```

**If you do not see “Logged-in user property”**

Check in order:

1. Is **Allow logged-in user property filters** **On** for this list? (Step 2)
2. Are you in **Filtering**, not Screen Visibility?
3. Is the switch locked because the app is not entitled? Ask admin/support.
4. Did you refresh / reopen the list after the feature was enabled?

**Optional: combine with a normal fixed filter**

You can add a second condition that still uses **Fixed value**, for example:

* Status equals `Open`

Then Alex sees North tasks that are Open.\
Jordan sees South tasks that are Open.\
Both conditions must be true.

***

#### Step 5 — Save / publish

1. Save your builder changes as you normally would.
2. **Publish** the app so end users get the new filter behavior.

Until you publish, people on the live link may still see the old unfiltered (or old cloned) lists.

***

#### Step 6 — Test the way a real employee would

Do not only glance at the builder preview if you can help it. Log into the published app (or use whatever “view as user” tooling you have) as two different people.

**Test A — Alex (Store = North)**

1. Log in as Alex.
2. Open **Tasks**.
3. Expect: Restock milk, Count till.\
   Do not expect: Fix freezer, Clean lobby.

**Test B — Jordan (Store = South)**

1. Log out; log in as Jordan.
2. Open the **same** Tasks screen.
3. Expect: Fix freezer only.

**Test C — blank Store (optional)**

1. Temporarily clear Store on a test user.
2. Open Tasks as that user.
3. Expect: **no tasks**.
4. Put Store back; confirm rows return.

If Test A and Test B both see the full unfiltered list, jump to [Troubleshooting](#troubleshooting-for-makers).

***

#### Step 7 — Clean up old clones (when you are ready)

After the single filtered list works:

1. Point navigation to the one Tasks list.
2. Remove or unpublish “North Tasks / South Tasks / East Tasks” clones.
3. Remove Screen Visibility rules that only existed to support those clones.

You can keep Screen Visibility for unrelated needs (for example, an Admin-only Dashboard). You just no longer need it to fake per-store lists.

***

### Another short example (same steps, different names)

**Scenario:** Support tickets should show only tickets for the agent’s **Team**.

| Database     | Property |
| ------------ | -------- |
| Tickets list | Team     |
| Users        | Team     |

Maker steps (abbreviated):

1. Open the **Tickets** list.
2. Turn **Allow logged-in user property filters** **On**.
3. In **Filtering**: `Team` equals **Logged-in user property** → `Team`.
4. Publish.
5. Log in as an agent on Team Alpha vs Team Beta and confirm different ticket sets.

Same feature, different property label.

***

### What end users experience

End users do **not** configure this.

They simply open the list and already see “their” rows. They will not see a special “logged-in user property” control. That control exists only in the builder for you.

They also should not be able to discover other stores’ rows through normal search or by opening a shared link to a row outside their filter — the platform enforces the filter when the feature is on.

***

### Fixed value vs Logged-in user property (decision guide)

Ask yourself:

> Should every person who opens this list see the **same** filtered set, or a set that depends on **who they are**?

| Answer                                               | Use                         |
| ---------------------------------------------------- | --------------------------- |
| Same for everyone (for example always hide Archived) | **Fixed value**             |
| Depends on the person (their store, team, region)    | **Logged-in user property** |

You can use both on the same list:

```
Store  equals  Logged-in user property → Store     ← dynamic
AND
Status equals  Open                                ← fixed
```

***

### Common mistakes (read this if it “does nothing”)

#### Mistake 1 — Toggle On, but value type still Fixed

Turning on **Allow logged-in user property filters** only *unlocks* the new value type.\
You must still open **Filtering** and change that filter’s value type to **Logged-in user property**.

#### Mistake 2 — Editing Screen Visibility instead of Filtering

Screen Visibility can already talk about the logged-in user for **showing/hiding the whole screen**, but it does **not** replace list row filters, and it does not use this new dual value-type control for content filtering.

For “same screen, different rows,” use **Filtering**.

#### Mistake 3 — Property mismatch

Examples that fail:

* Tasks.Store is a Relation; Users.Store is a Text string “North”
* Tasks uses option `North Branch`; Users uses option `North`
* You filtered Tasks.Location but selected Users.Store by accident

Align names, types, and actual values in the source data.

#### Mistake 4 — Testing with only one user

If you only ever log in as yourself, you cannot tell whether the filter is dynamic. Always test with two users who have **different** Store (or Team) values.

#### Mistake 5 — Expecting empty Store to show everything

Empty user property → empty list. Fill the user profile, or temporarily use a fixed filter while you clean data.

#### Mistake 6 — Leaving old clone screens in the nav

People may still open “South Tasks” (fixed filter) instead of the new shared Tasks list. Update navigation after you migrate.

***

### Turning the feature off for one list

If a list starts behaving wrongly and you need a quick revert:

1. Open that list in the builder.
2. Set **Allow logged-in user property filters** to **Off**.
3. Publish.

User-property filter values on that list stop applying. Your fixed-value filters keep working. Other lists are unchanged.

You can also delete or change the specific filter condition back to **Fixed value** if you only want to undo one condition.

***

### Troubleshooting for makers

| What you see                                   | Likely cause                                            | What to do                                                                                      |
| ---------------------------------------------- | ------------------------------------------------------- | ----------------------------------------------------------------------------------------------- |
| “Allow…” switch locked                         | Plan is Free/Plus, or feature disabled for this app     | Upgrade to **Pro or above**, or contact admin/support to enable logged-in user property filters |
| No “Logged-in user property” in the value menu | Per-list switch is Off, or you are in the wrong section | Turn the switch On; edit **Filtering** on a List                                                |
| Everyone sees all rows                         | Still using Fixed value, or not published               | Set value type correctly; publish; hard-refresh the live app                                    |
| Everyone sees zero rows                        | User Store empty or properties don’t match              | Fix Users data; confirm property types                                                          |
| Only my user looks correct                     | Others have wrong/missing Store                         | Audit the Users database                                                                        |
| Preview looks fine, live app doesn’t           | Not published / cached old build                        | Publish again; retest in a private window                                                       |
| I changed Visibility and nothing happened      | Wrong feature surface                                   | Use list **Filtering** as in this guide                                                         |

***

### Limits makers should know

* Requires a **Pro or above** subscription (Pro, Premium, Enterprise). Not available on Free or Plus.
* This is for **list Filtering** (which rows appear on a list). It is not a redesign of Screen Visibility.
* It does not replace **Data Restriction**. If your org already uses Data Restriction for hard database ACL, keep that; this feature is the list-level “show the right rows on this screen” tool.
* If the logged-in user’s property is missing, the list shows **no matching rows** rather than all rows.
* You need the per-list allow switch **On** before the new value type appears.

***

### Quick checklist (print / paste into a ticket)

* [ ] Account is on **Pro or above** (not Free or Plus)
* [ ] Users database has the property (for example Store) filled for test users
* [ ] List database has a matching property (for example Store)
* [ ] Open the **one** shared list in the builder
* [ ] **Allow logged-in user property filters** → **On**
* [ ] Open **Filtering** (not Screen Visibility, not In-App Filtering)
* [ ] Add/edit filter: list property **equals**
* [ ] Value type → **Logged-in user property**
* [ ] Pick the matching user property
* [ ] Optional: add fixed filters (Status = Open, etc.)
* [ ] Publish
* [ ] Log in as User A and User B with different property values
* [ ] Confirm each sees only their rows
* [ ] Remove old per-store list clones when ready

***

### One-page recipe (copy this)

**Goal:** One Tasks list, filtered by each employee’s Store.

1. Builder → select **Tasks** list
2. **Logged-in user property filters** → allow **On**
3. **Filtering** → `Store` equals **Logged-in user property** → `Store`
4. Publish
5. Test as Alex (North) and Jordan (South)

That is the whole feature for makers.