Before the first share: show new users exactly who can see their work
Help first-time authors choose an audience, understand access levels and check the recipient experience before sharing or publishing their work.
In this article
A first share should begin with a clear answer to two questions: who will be able to open this work, and what will they be allowed to do? A copied link answers neither question by itself.
A product may support invitations to named people, access for anyone holding a link and public publishing. These options can sit close together in the interface while creating very different audiences. Onboarding should make the resulting access visible before the author sends the link or publishes the page.
Start with the intended collaboration. A client reviewing a proposal, a teammate editing a document and a visitor reading a public guide need different permissions. The first-use flow should help the author choose among those outcomes without requiring them to decode a permissions model from scratch.
Put audience before the copy button
Consider an illustrative document product in which a new user has drafted a supplier brief. They want one colleague to review it and leave comments. The share dialog should first identify that colleague and the intended permission, then provide the invitation or link appropriate to the choice.
A clear confirmation would say that the named colleague can comment on this brief. It would also show whether any broader workspace or link-access rule already applies. The author needs the effective audience, including access inherited from elsewhere, rather than just the last permission they changed.
Notion’s sharing documentation distinguishes invited people, workspace access and anyone on the web with the link. It separately describes permission levels such as viewing, commenting and editing. That separation is useful: audience and capability are two decisions, even when a product presents them in one dialog.
For the fictional supplier brief, “Copy link” can remain available after the choice. Its supporting text should explain whether the link grants access or merely takes an already authorized person to the page.
Make broader access a visible decision
A link that works for anyone who receives it is convenient. It also means the audience can extend beyond the person the author initially sends it to. Explain that effect where the author selects the option.
Do not describe link access as private merely because the URL is long or difficult to guess. If possession of the link is enough to open the content, say that. If the recipient must sign in or use an invited identity, explain that requirement before the author sends them away to discover it.
Public publishing deserves its own preview of the resulting experience. A page intended as a website may include navigation, related pages or other material the author did not consider part of the first share.
Notion’s publishing guide notes that publishing can include subpages and provides a separate search-engine-indexing setting. Access on the web and eligibility for search discovery should therefore be explained separately. Disabling search discoverability does not turn an otherwise accessible page into an invitation-only document.
Keep the explanation tied to the actual product. A general warning about “public data” is less useful than showing exactly which page and related content will be accessible under the selected setting.
Review the share from the recipient’s position
An author often has broad access to their own work. Opening the link in the same session can confirm that the page exists without demonstrating what a recipient will see.
For the fictional supplier brief, a recipient preview could show the page title, the selected comment permission and any sign-in requirement. If the product can truly simulate the recipient’s permissions, explain whose view it is showing. If it is only a visual preview, keep that limit clear.
A controlled internal review should also use a separate test identity with the intended access. Check whether the brief opens, whether commenting works and whether editing remains unavailable. These are proposed acceptance checks, not a claim that a live product was tested for this article.
For a public page, a signed-out view can help inspect the anonymous experience. It does not prove every authenticated permission combination is correct. Review the audience that matches the actual first-share decision.
The useful output is a specific observation: the invited reviewer reached the intended brief and could leave a comment. “The link opened” is too broad to establish that outcome.
Show the scope of inherited access
A document can look restricted in one place while remaining available through a parent page, workspace or other permission path. The first share is a good moment to make those relationships understandable.
Notion documents that subpages inherit the permissions of their parent page, with page-level changes available. For a product using that model, the share dialog should explain the source of existing access rather than presenting a list of names without context.
In the illustrative supplier brief, suppose the document sits inside a team folder. The author adds one reviewer, but the team folder already grants viewing access to several colleagues. The confirmation should not imply that only the newly invited person can open the brief.
A compact line such as “Also visible to members of the Operations folder” can communicate the broader scope, with a path to inspect or change it where the author’s permissions allow. The exact wording and control depend on the product’s real access model.
The author should not need to learn the entire hierarchy during signup. They do need to understand the part affecting the document they are about to share.
Make taking access back understandable
Before the first share, provide a visible route back to access settings. Explain what can be revoked and avoid implying that previously viewed or copied information can be recalled from every recipient.
For a named invitation, the author may need to remove that person’s permission. For link access, they may need to disable the general-access rule. For a published page, they may need to unpublish it and inspect any separate sharing path.
Notion’s documentation offers a concrete example: unpublishing a site can leave link access available if the page still allows anyone with the link. The interface should help the user understand the resulting access after a change, not merely confirm that one publishing switch is off.
In our fictional product, the revocation confirmation names the effect: “This link no longer opens the brief for people without another permission.” That last condition matters if workspace membership or a named invitation still grants access.
A useful first share is a completed collaboration
For the supplier-brief example, the onboarding journey ends when the intended colleague reaches the correct document with the intended permission and the author understands how to adjust that access. Sending an invitation is an earlier step, not the full collaboration outcome.
When reviewing the flow, ask the author to predict who can open the brief before they share it. Then compare that expectation with the recipient experience. A mismatch is a concrete design finding: the interface has taught the wrong audience model.
Keep the final confirmation connected to the work. Show the shared document, the people or access rule involved and the next useful action, such as reviewing the colleague’s comment. The first share should make collaboration feel understandable, with a clear boundary around who has been invited into it.
