Notion at Work: The Full Scope of Sharing and Permissions

Notion’s sharing model hinges on a practical “hierarchy” of who can see what—public pages, invited guests, workspace members, and groups—plus a crucial rule: sharing a database view effectively grants access to the full underlying database. That combination determines how safely teams can collaborate and how carefully admins must structure permissions to avoid accidental overexposure.

At the top level, pages can be made public or shared with specific people. Public sharing is controlled through a share menu that toggles “public access” and sets an access level: “can read” for anonymous visitors, or “can’t comment” vs comment-enabled access for logged-in users. Admins can also allow search engines to index the page (disabled by default) and decide whether duplication is allowed (enabled by default), letting logged-in users copy the page as a template. Once public access is configured, a unique URL can be copied and shared; settings can be revisited later to revoke public access.

For controlled access, Notion requires invitees to be signed in. If an email isn’t tied to an existing account, the invite prompts account creation and onboarding. The system distinguishes between “guests” (typically contractors, clients, or partners) and “members” (team/enterprise workspace participants). Both can be granted page-level permissions, but the permission granularity matters: “can read” and “can comment” limit what users can do, while “can edit” allows changes without granting sharing power, and “full access” includes the ability to invite others—often too permissive for external collaborators.

Permissions also extend beyond individual people through workspace-wide access and groups. A page can be toggled to “workspace access,” which moves it into the workspace category for all members, with a default permission of full access that can be reduced to can read or can comment. Groups—created by admins—let teams grant access to a set of users as a unit (for example, a marketing group), avoiding repetitive per-person sharing.

A key nuance appears in how Notion handles page structure and database relationships. When a page is shared, sub-pages created within it via page blocks are shared too. More importantly, sharing a view of a database or a linked database can expose more than intended: the full original database becomes accessible. The presenter flags a hoped-for improvement—sharing database views without granting access to the entire database—but for now recommends workarounds such as building client “portal” pages with simplified, filtered representations rather than exposing a master database wholesale.

Admin controls round out the model. Admins can manage guests and members, convert guests to members on team/enterprise plans, remove users, and create or manage groups. Security settings can restrict sharing behaviors, including preventing public sharing and disabling guests from sharing with non-members. In the Q&A, several practical scenarios are addressed: external sharing can’t be made truly “unshareable” if someone has full access; requiring sign-in and limiting permissions can prevent further sharing. For database-linked structures, linked databases remain protected unless explicitly shared. Finally, Notion can function as a private community space (often better than Facebook groups for structured collaboration), though membership-site features like dated releases aren’t automated—tiered access can be approximated using groups and page-level permissions.