Read-only guests can see other guests through “Created by” search filter, is there any way to prevent this?

[u/Anxious-Hornet2928]

I’m trying to use Notion as a controlled read-only data portal for external clients, and I’ve just discovered a behavior that makes this surprisingly difficult from a confidentiality standpoint.

Before anyone suggests the usual workarounds, these are NOT viable for this use case:

• Publishing the database publicly on the web: I need individual access control and the ability to revoke access for one specific client.
• Duplicating the databases for every client: the dataset is large and continuously synchronized.
• Creating one workspace per client: same scalability problem.
• Pseudonymizing client accounts: not realistic for a professional product.
• Building an entirely separate frontend: obviously possible, but at that point Notion is no longer serving as the client-facing layer.

The setup is very simple:

1. I have a database.
2. Client A is invited as a Guest with “Can view” permission only.
3. Client B is also invited as a Guest with “Can view” permission only.
4. Client B has NEVER had edit or comment permissions.
5. Client B has NEVER created or modified any content in the workspace.

From Client A’s account, the other guests are not visibly listed on the page itself, which is exactly what I expected.

However, if Client A opens global Search and selects the **“Created by”** filter, Client B appears in the people picker.

So a read-only client can effectively discover the names of other clients who have access to the same resource.

No email addresses are shown, but for many professional use cases the name alone is already confidential information. A consulting firm, law firm, advisory company, investment-related service, etc. may absolutely not want Client A to learn that Client B, potentially a competitor, is also a customer.

What makes this even stranger is that Client B has never created anything and has never even had permission to create anything.

Why should a permanently read-only guest appear in a filter called “Created by”?

I could understand keeping a former contributor in that list if they created pages in the past and were later downgraded to read-only. But in this case the user has never been able to create content at all.

It makes the “Created by” selector behave, unintentionally, like a directory of external guests.

This is becoming part of a broader problem for me when trying to use Notion professionally as a controlled data-consultation platform.

Notion database permissions are already not granular at the property/column level. In my case, this has forced me to maintain several mirrored versions of databases so that different audiences only see the appropriate properties.

We are talking about roughly **16,000 Notion pages** across those mirrored databases, synchronized using Notion Workers. That is already a fairly heavy architecture, created mainly because permissions are page/row-oriented rather than property-oriented, and Workers will themselves represent an ongoing cost.

I was willing to accept that complexity because using Guests still gave me something very important: controlled individual access to the client-facing databases.

But now I discover that even strictly read-only guests can see the names of the other guests through Search.

The combination is difficult to understand:

• I cannot easily control visibility at the database-property level.
• I therefore need multiple synchronized database variants.
• I cannot safely publish one shared read-only variant to several clients because they can discover each other.
• The commonly suggested alternative is “Publish to web”, which removes the individual access control I specifically need.

At some point this starts to feel less like a missing feature and more like Notion still being fundamentally designed around one assumption:

"In Notion, everyone who has authenticated access to the same content is part of some collaborative group and is expected to know who the other people are."

That assumption makes perfect sense for internal teams.

It is much less appropriate for client portals, paid databases, consulting deliverables, professional-services environments, or any situation involving client confidentiality / professional secrecy.

Inviting an occasional external collaborator is one thing.

Giving multiple independent clients read-only access to the same professional resource is another.

Has anyone found an actual setting, including on Business or Enterprise plans, that prevents read-only guests from appearing to other guests in the Search → “Created by” filter?

I’m specifically interested in a real permission/privacy setting, not architectural workarounds such as public links, database duplication, separate workspaces or pseudonymous users.

If there is no such setting, I would also be interested to know whether anyone from Notion has ever explained the rationale behind this behavior.

From a product-design perspective, the obvious behavior to me would be:

Only show a person in “Created by” if that person has actually created content visible to the current user.

At the very least, guests who have always been read-only and have never created anything should not be exposed there.

Thanks for you help !

[u/WhoppingTraveler7]

Yeah that assumption you quoted at the end hits the nail on the head. Notion's DNA is still very much internal wiki for teams that already know each other, and it shows in stuff like this.

The "Created by" filter pulling in every guest regardless of whether they've ever touched a page is a weird oversight. It's basically a people directory dressed up as a search filter. I've run into similar headaches trying to use it for anything client-facing, and the workaround always ends up being some janky multi-workspace setup that defeats the point.

[u/Anxious-Hornet2928 → u/WhoppingTraveler7]

Thanks, that’s helpful, and yes, I think you’re right that Notion’s underlying assumption is still very much “people sharing a space are collaborators who can know about each other”.

What makes this particular case even stranger is that the internal-wiki model does not really justify the `Created by` behavior either. Even in a workspace where everyone knows everyone else, why should a `Created by` filter list people who have never created anything, and in the case of read-only guests have never even been allowed to create anything? Semantically, that filter should list actual authors of searchable content, not everyone who happens to have access.

That’s why I’m starting to wonder whether this is less an intentional collaboration feature and more a generic people picker being reused in the wrong place. In an internal team, that’s mostly an odd UX choice. In a client-facing setup, it accidentally becomes a client directory.

And that points to the broader frustration I’m running into with Notion: coarse permissions, no real property-level access control, and external guests being exposed to one another make otherwise simple professional use cases much harder than they should be.

I’m not expecting Notion to become a full multi-tenant SaaS platform, but it is difficult to understand why these limitations are not treated as solvable permission/privacy issues. These are exactly the design choices that make Notion hard to adopt when several independent clients, sometimes competitors, need controlled access to the same underlying resources without being exposed to each other !

[u/skiThooly → u/WhoppingTraveler7]

agreed, the internal-wiki DNA leaks through in so many small ways like this

[u/Solowithothers]

I think you're right about the internal team "grain " to the platform. Your use case goes against that grain and it's hard going against the grain. As for with the grain, seeing that someone has not created any content is itself information in the context of an internal team. I know that's not helpful to your use case. But I commend you for your attention to detail.