Member, guest, or something else? A guide to deciding who sees what in Notion

Every permissions mess I’ve untangled for a client starts the same way. Someone made everyone a member because it was the fastest option, or added a client as a guest and can’t figure out why they can’t see the project plan. None of it is actually complicated once you know the real categories.

The four types of people in a Notion workspace

Members are your company, full stop. They belong to the organization, they’re billed per seat on paid plans, and by default they can see anything shared with the whole workspace. If you’re wondering whether someone should be a member, ask yourself: do they work for you, and do they need to see most of what gets built in Notion? If yes, member.

Multi-seat guests (Notion calls them “member restricted”) are the option almost nobody uses, and almost everybody should use more. They cost exactly the same as a regular member on your bill, but they don’t get access to the whole workspace by default. They only see the teamspaces and pages they’ve actually been added to. They can still use Notion AI, log in via SSO, and be added to permission groups. The real difference: they can’t create teamspaces, and can only share pages with people who already have access to the same content. Use this for a contractor who’s fully embedded in a team but has no business browsing the rest of your organization.

Guests are external. Clients, freelancers, a partner agency: anyone outside your organization. They get no overview of the workspace, they’re invited page by page, and they don’t count against your paid seats. They do count against your plan’s guest limit. Free and Plus cap you at 10 guests total across the entire workspace. Business and Enterprise remove that cap entirely.

Temporary members exist for one specific case: a consultant working in your space for a fixed period. They get member-level access, an admin sets an expiration date up to a year out, and on that date access disappears automatically. Nobody has to remember to revoke it. And they don’t use a paid seat.

On top of these four profiles, there are two admin roles: workspace owners (can do everything, including manage billing) and member admins (Enterprise only, can manage access without touching workspace settings).

The six permission levels, and where people get it wrong

Every shared page gets one of these six levels:

• Full access: can edit anything, and can share the page with others. Often one notch too generous when it’s chosen by default out of convenience.
• Can edit: can change the content, but can’t share it. This is what most collaborators actually need.
• Can edit content (databases only): can create and edit pages inside a database, but can’t touch the structure (properties, views, sorts, filters). This level stops your database from being quietly wrecked by someone adding a random property.
• Can create (databases, Business and Enterprise only): can add new entries without seeing anyone else’s. Built for submission forms (tickets, applications, requests).
• Can comment: can leave comments, nothing else. Useful for review cycles where you want zero risk of someone editing.
• Can view: read-only. No comments, no edits, no sharing.

The mistake I see most often: someone shares a database with an entire teamspace at “full access” because that’s what the dropdown defaulted to. Six months later, properties have been renamed, two views have vanished, and nobody knows why. Full access should go to the people who actually own the structure, not everyone who touches the data.

The rule that overrides everything if you don’t know it

This is the one that trips up even careful people: Notion always applies the widest access a person holds, no matter where it comes from. If you give someone “can view” on a specific page, but they’re also in a group that has “full access” on the parent page, full access is what applies. The carefully configured restriction doesn’t win.

In practice: before you restrict someone’s access, check every other way they might already be able to reach that content — workspace-wide sharing, group membership, parent page permissions, a teamspace default. A restriction set with good intentions isn’t one if there’s still a wider door open somewhere else.

Giving each person their own slice of a shared database

If your database has a Person-type property (an assigned owner, a responsible party), you can set row-level access rules tied to that property. Available on Business and Enterprise only.

This is what lets a recruiter give each hiring manager visibility into only their own candidates, or a team of contractors edit only their own assigned tasks in a shared tracker, without opening up the rest of the database. It’s one of Notion’s most underused features, and it’s usually the answer when someone asks “can I let everyone see only their own items in a shared database?”

One subtlety worth flagging: if the person has no other access to the database itself, they can’t open it directly. They only see the rows assigned to them, through their notifications inbox or a linked view you build for them. If you also want them to be able to create new entries, row-level access alone isn’t enough, you’ll need a form.

Member, multi-seat guest, guest, or temporary: deciding fast

• Works for you, needs to see most of Notion: member.
• Works for you or is fully embedded in a team, but has no business in the rest: multi-seat guest.
• Doesn’t work for you, only needs specific pages: guest, as long as you’re under your plan’s limit.
• A consultant or contractor for a fixed period: temporary member, so nobody has to remember to revoke access later.

Getting this wrong in either direction is expensive. Make everyone a member, and you’re paying for seats that should have been free guest access. Make everyone a guest, and you either hit the limit, or worse, grant someone broader access than you realize because of the widest-access rule.

If you’re looking at a workspace where half the team can see things they shouldn’t, and the other half can’t see what they need, that’s simply what happens when nobody set this up deliberately from day one. It’s also one of the fastest things to fix, once someone does the actual pass on who needs to see what.