I didn't think Notion would ever fix this

Notion’s biggest collaboration gap isn’t offline access—it’s database permissions that can’t be scoped to the “slice” of data people need. That limitation forces teams into blunt choices: either remove access entirely and re-add individuals page-by-page, or grant everyone access to the whole database and rely on workarounds that can leak sensitive information. The result is extra administrative overhead and, in client-heavy setups, a real risk that clients see more than they should.

The core problem is how Notion currently handles permissions. Permissions are set at the database level or at the individual page level—there’s no way to grant access based on a filtered view (the way an SQL-backed app might). For example, a team can create a centralized task database and a filtered view showing only tasks assigned to Alex. But Alex still needs access to the entire database to see his filtered results, meaning he can also view other people’s tasks by creating his own unfiltered view or using search. In practice, that pushes organizations toward either duplicating databases, splitting work across multiple spaces, or manually managing access for each page.

Freelancers and agencies feel the pain most when they try to build client services dashboards. A common setup is a single database that tracks work across multiple clients, with the expectation that each client will only see their portion. Without view-based permissions, that expectation breaks: clients may end up with access to confidential information belonging to other clients. Some teams attempt clever workarounds, but the transcript frames them as insufficient, leaving the Notion API as the only reliable escape hatch—extracting data from a locked-down database and duplicating it into a more open database or a third-party client portal tool.

Hope arrives via a public Notion tweet tied to a hiring workflow mock-up presented by Sam Catania, a Notion product manager. In the permissions area shown in that presentation, there’s a more granular concept: “can edit” and “can view properties,” with automations that can change permissions as a workflow advances and trigger notifications at different stages. The transcript doesn’t confirm whether this is a finished feature or a mock-up, but it treats Notion’s decision to publicly highlight it as a meaningful signal that the company is moving toward a permissions model that can react to workflow context.

The argument then shifts from diagnosis to priority-setting. The transcript’s stance is that better permissions should outrank other feature bets—especially AI—because Notion is fundamentally a collaborative platform where teams increasingly need to build internal software-like systems. The proposed improvements include making the permissions work for guests (not only members), integrating permission changes with automations and filters so tasks can automatically inherit access rules, and providing a clearer, centralized way to see who can access a page without confusion between share settings and the new permissions controls. If delivered, the change would reduce manual overhead, make client dashboards safer, and reduce the need to “turn Notion into a backend” using external tools.