Member, guest, or something else? A permissions decision guide

The four types of people in a Notion workspace

Members are your company, full stop. They're inside the organization, they get 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: do they work here, and should they see most of what we build in Notion? If yes, member.

Restricted members 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 workspace-wide access by default. They only see the teamspaces and pages they've actually been added to. They can still use Notion AI, log in with SSO, get added to permission groups. The only real difference: they can't create teamspaces, and they can only share pages with people they already have shared access alongside. Use this for a contractor who's fully embedded in one team but has no business browsing the rest of your organization.

Guests are external. Clients, freelancers, a partner agency, anyone outside your organization. They don't get a workspace-wide view of anything, they get invited page by page, and they don't count toward your paid seats. They count toward your plan's guest limit instead. Free and Plus cap you at 10 guests total across the whole workspace. Business and Enterprise remove that cap.

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

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

The six permission levels, and where people actually mess them up

Every page, when you share it, gets assigned one of six access levels:

• Full access: can edit anything, and can share the page with others. This is the level people default to out of laziness, and it's usually one notch too generous.
• Can edit: can change the content, can't share it with anyone else. This is what most collaborators actually need.
• Can edit content (databases only): can create and edit pages inside a database, and edit property values, but can't touch the database's structure (properties, views, sorts, filters). This is the level that saves your database from getting quietly wrecked by someone adding a random new property.
• Can create (databases only, Business and Enterprise): can add new entries but can't see or edit anyone else's. Built for exactly one situation: a form where people submit things (IT tickets, requests, applications) without being able to browse what everyone else submitted.
• Can comment: can leave comments, nothing else. Good for review cycles where you want feedback, not edits.
• Can view: read-only. No comments, no edits, no sharing.

The mistake I see constantly: someone shares a database with a whole teamspace at "full access" because it was the default in the dropdown, then wonders six months later why half the properties have been renamed and two views have disappeared. Full access should be reserved for people who actually own the structure, not everyone who touches the data.

The rule that undoes half of the above if you don't know it

Here's the one that trips up otherwise careful people: Notion always applies the broadest access a person has, from any source. If you give someone "can view" on a specific page, but they're also a member of a group with "full access" to the parent page, they get full access. The narrower permission you carefully set doesn't win. The broadest one does.

Practical takeaway: before you lock down access for someone, check every other way they might already be touching that content — workspace-wide sharing, group membership, a parent page's permissions, a teamspace default. A restriction you set with good intentions is not a restriction if there's a wider door left open somewhere else.

Giving one person their own slice of a shared database

If your database has a person property (an assignee, an owner), you can set page-level access rules tied to that property. Business and Enterprise only. This is how a recruiter can let each hiring manager see only their own candidates, or how you can let a team of contractors edit only their own assigned tasks in a shared tracker, without opening up the rest of the database to them.

One quirk worth flagging: if the person has no other access to the database itself, they can't browse it directly. They only see the specific rows assigned to them, surfaced through their notifications inbox or through a linked view you build for them. If you want them to create new entries too, page-level access alone won't do it, you'll need a form.

Member, restricted member, guest, or temporary: how to decide quickly

• Works at your company, needs to see most of what's in Notion: member.
• Works at your company or is deeply embedded with one team, but has no business browsing everything else: restricted member.
• Doesn't work at your company, only needs specific pages: guest, as long as you're under your plan's guest limit.
• A consultant or contractor working for a set period: temporary member, so nobody has to remember to revoke access later.

Get this wrong in either direction and it costs you. Make everyone a member and you're paying for seats that should've been free guest access. Make everyone a guest and you'll hit the guest limit, or worse, quietly grant workspace-wide access anyway because nobody remembered the broadest-access rule above.

If you're staring at a workspace where half the team has access to things they shouldn't, and the other half can't see things they need, that's not a you problem. That's just what happens when nobody set this up deliberately from day one. It's also one of the fastest things to actually fix, once someone maps out who should see what.