Flow Sharing

Sharing, Invites & Collaboration

Overview

Sharing succeeds when the sharer can answer "who can do what?" at a glance and the recipient lands in the content with the right access in one click. Every extra decision at share time, and every dead end at open time, kills the loop that grows collaborative products.

When to Use

• Adding a Share button and dialog to any document, project, file, or workspace
• Designing permission levels and link-based access
• Building team invite flows — email, link, or both — or access-request handling
• Adding presence, live cursors, or activity indicators to collaborative surfaces
• Not for: social-network posting and feeds
• Not for: OS share sheets when you're only a data provider — those distribute a link; they can't set permissions

The Proven Flow

1. Share button

   • Top-right of the content it shares, labeled with the word "Share" — not icon-only. Figma, Google Docs, Notion, and Dropbox all converge on this exact placement.
   • Opens a popover or modal scoped to this object, never a trip to a settings page.

2. Share dialog — one dialog, three zones (the Google Docs model, since converged on by Figma, Notion, and Dropbox)

   • Invite row (top): one combined input accepting emails and names of existing members, multi-entry chips, with a permission dropdown attached to the input. Explicit "Invite"/"Send" button — Enter adds a recipient chip, never sends. Default role: can-edit for teammates, can-view for external addresses. Optional "notify people" toggle with a message field, collapsed by default.
   • People list (middle): everyone with access — avatar, name/email, per-person permission dropdown that includes "Remove." Owner is marked and immovable. Inherited access shows its source: "Everyone at Acme can view (via Team folder)" — never anonymous magic access.
   • Link zone (bottom): general-access control plus a Copy link button. Copy link is the highest-traffic action in the dialog — one click, "Link copied" feedback within 100ms, never buried in a submenu.
   • Viewers and commenters can open the dialog to see who has access; only roles at-or-above their ceiling are offerable.

3. Link sharing states — ordered by exposure, defaulting safe:

   1. Restricted (default): the link works only for invited people. This must be the default — every leaked-link incident starts with a permissive default.
   2. Anyone in [org] with the link — role selectable: viewer / commenter / editor.
   3. Anyone with the link — role selectable; editor-via-public-link deserves an extra warning.
   • Changing state shows a plain-language consequence sentence: "Anyone on the internet with this link can view." That's Google Docs' literal copy — consequences, not jargon like "public link enabled."

4. Permission levels — four canonical roles; don't invent more until proven necessary:

   • Viewer — read only.
   • Commenter — read + comment. Critical for review workflows; when it's missing, people over-grant edit.
   • Editor — modify content; can invite others up to their own level (make this configurable).
   • Owner / Full access — everything, plus sharing control, delete, and transfer.
   • Name roles by capability ("Can edit"), never by org title ("Manager"). Notion's "Full access / Can edit / Can comment / Can view" is the reference wording.

5. Recipient experience — the half everyone forgets

   • Invite email: sharer's real name and avatar as sender context, the object's title, one large CTA ("Open the document"), plus the sharer's message if any.
   • Clicking lands the recipient inside the content. Auth happens inline if needed, and after signup they land in the same content — not on a dashboard. Deep-link persistence through the auth flow is the single most-fumbled step in sharing.
   • New-user invites: minimal signup (name + password, or SSO), and no onboarding tour standing between them and the shared thing.
   • Link unfurls respect permissions: a restricted document pasted into Slack or iMessage shows a generic card, never the content — OG previews are an access-control surface.
   • Invite emails come from a consistent, authenticated sender domain (SPF/DKIM) with the sharer in the reply-to; collaboration invites that land in spam kill the whole loop.

6. Access request — permission-denied done right

   • A signed-in user without access hits the link → never a bare 403 or fake 404. (Genuinely sensitive tiers may hide even the title — decide per product.)
   • Screen shows: object title, "You need access," a Request access button, and "You're signed in as jason@… — switch account." Wrong account is the #1 cause of false denials; Google Docs handles both cases on one screen.
   • The request notifies the owner (email + in-app) with one-click actions: Approve as viewer / Approve as editor / Deny.
   • The requester is notified on approval and lands directly in the content.

7. Revoking access — the forgotten reverse path

   • Per-person "Remove" in the people list, effective immediately, including live sessions.
   • Flipping a link back to Restricted cuts off everyone who arrived by link; warn with the count: "This will remove access for 12 people."
   • The removed person's next visit gets the request-access screen, not an error — they may legitimately need access again.
   • Ownership transfer is explicit and accepted by the recipient, never a silent swap; the old owner drops to editor, not to nothing.

8. Team invite flow (workspace level)

   • Offer both channels: email invites with a role selector, AND an invite link ("Anyone with this link joins as Member") with regenerate and disable controls.
   • Show pending invites with resend and revoke.
   • If seats are billed, show the cost consequence at invite time — "Adding 2 editors adds $24/mo" — before send, not on the next invoice (Figma's seat-confirmation model).
   • Auto-suggest teammates by verified email domain: "3 people from acme.com are already here — join them." This is Figma's and Notion's domain-capture loop — it grows teams without sending a single unsolicited email.

9. External guests vs members

   • Distinguish visually: external collaborators get a "Guest" badge in people lists and avatar stacks (Notion, Slack Connect) — internal users must see at a glance when outsiders are in the room.
   • Guests are scoped to invited objects only; they never see the workspace directory or member list.
   • Escalation request: when an editor tries to grant beyond their own rights, convert the attempt into a request to the owner — "Ask Maria to make this public" — instead of a dead-end error.

10. Presence & collaboration cues — layer by intrusiveness:

• Avatar stack (top-right): overlapping avatars, "+3" overflow, max ~5 shown.
• Live cursors with name labels — canvas and document surfaces only (Figma's signature).
• Selection/field highlights in each collaborator's color.
• "X is editing" indicators on shared fields where cursors don't apply.
• Colors are assigned per person and stay consistent within a session. Presence decays honestly: idle state after ~1–5 minutes, gone on disconnect.
• Add "viewed by" history only where it's socially expected (work docs), and disclose it — silent read receipts read as surveillance.
• @mentioning someone without access prompts inline: "Maria can't see this — invite as commenter?" (Google Docs). Mentions are the highest-intent sharing signal in the product; never let them silently fail.

Layout & Structure

• Dialog size: ~480–560px wide on desktop; full-height sheet on mobile. Invite input pinned top, people list scrolls in the middle (fixed max-height — the dialog doesn't grow), link controls pinned bottom.
• One permission-dropdown component everywhere — identical wording and options in the invite row, people list, and link zone. Divergent permission UIs are how "I thought they could only view" happens.
• Copy link: always visible in the dialog, plus a right-click / overflow-menu shortcut on the object itself.
• Avatar stacks: 24–32px avatars, ~30% overlap, deterministic order (owner first, then recency), overflow count clickable to open the full list.
• Role dropdown order: most restrictive first (Viewer → Commenter → Editor) so misclicks fail safe.
• Permission checks server-side, always: the dialog is a view of access control, not the enforcement — a hidden button is not a denied request.
• Native mobile: the in-app share dialog handles permissions; the OS share sheet (UIActivityViewController / Android Sharesheet) distributes an already-permissioned link. Don't rebuild the OS sheet; don't make it the only path.
• Notification budget: one email per invite, one per access request, one per approval. Batch comment and edit activity into digests. Every collaboration email type gets its own notification setting.
• Keyboard and screen readers: the share dialog traps focus while open; the permission dropdown is a real listbox/menu with the current role announced; "Link copied" fires an aria-live announcement, not just a visual toast.
• Empty state: a never-shared object's dialog shows the invite input focused and one line of reassurance ("Only you can see this") — not a blank list.
• Audit trail (team products): owners can see who granted what to whom and when; permission changes without history are unresolvable disputes waiting to happen.

Viral Loops Without Spam

• A durable loop means the user shares for their own benefit — getting feedback, handing off work — and growth is the side effect. Figma files, Google Docs, and Calendly links work because sharing is the job, not a growth hack bolted on.
• Send invites only on explicit user action, previewing exactly who will be emailed before send. Never auto-email "suggested contacts," never pre-check bulk address-book invites, never send on the user's behalf without preview. LinkedIn's address-book import campaigns are the cautionary tale — lawsuits included.
• Incentivized referrals (Dropbox's storage-for-both) stay honest when the reward is two-sided, disclosed inside the invite ("Jason gets extra storage if you join"), capped, and the invite is visibly from the user, not the brand.
• Domain capture beats contact scraping: "people from your company are already here" converts without emailing anyone.
• Measure the loop honestly: invites sent → invites accepted → invitees who activate. A high send count with low acceptance means you're generating spam, not growth.

Quick Reference

Anti-Patterns