Invite by email
Invite specific people to a doc or folder by email, pick read or write, the access persists across sessions. They don't need an account yet — invites bind on first sign-in.
The People tab in the share dialog handles person-by-person access. Type an email, pick a level, send the invite — the recipient gets access bound to their email address. Works for both documents and folders.
Sending an invite
| Step | What happens |
|---|---|
| 1. Open the doc or folder; click Share | Share dialog opens |
| 2. Stay on the People tab (the default) | List of current collaborators and pending invites loads |
| 3. Type the recipient’s email | The level dropdown defaults to Read |
| 4. Pick Read or Write | (See Permissions for what each can do.) |
| 5. Click Invite | The invite is created server-side and an email is sent |
The recipient appears in the dialog under Pending invites with their email, the level you picked, and a Cancel button.
What the recipient receives
The invite email links them to my.sweetdocs.app with a short-lived token tied to the resource and level. Two cases:
| Recipient state | What they do | Result |
|---|---|---|
| Already signed up to sweetdocs (any plan) | Click the link, sign in if needed | The doc / folder appears in their Shared with me view immediately |
| Not signed up yet | Click the link, sign up (free) | The invite is bound to their account on sign-up, and the resource appears in their workspace |
Sweetdocs binds invites by email, so even if the recipient signs up before clicking the link, their pending invites auto-claim when their account’s email matches.
Levels you can grant
The People tab exposes two levels for invites:
| Level | What they can do |
|---|---|
| Read | View the doc; cannot edit |
| Write | View, edit, and add comments |
A third level — Manage — exists in the ACL but is reserved for the document owner and explicit ownership transfers. See Permissions for the full role grid and what each level lets a collaborator change about sharing itself.
Pending vs. active
Two row types appear in the dialog:
| Type | Appearance | What it means |
|---|---|---|
| Pending invite | Email address + “Pending” pill + Cancel | The invite is sent but not yet accepted by the recipient |
| Active collaborator | Name (or display name) + avatar + level + Remove | The recipient has accepted and now has access |
Pending invites can be canceled at any time before they’re accepted — the invite row is deleted, and the email link stops working. Active collaborators can be removed to revoke access.
Folder sharing cascades
When you share a folder, every document inside it inherits the share (read or write). Adding a new document to that folder later automatically gives the same collaborators access. No need to re-share each doc.
This is the simplest way to give a team standing access to a body of work: share the folder once.
Revoking access
| Action | Effect |
|---|---|
| Click Remove on a person’s row | Their ACL entry is deleted; on their next page load they lose access |
| Click Cancel on a pending invite | The invite token is invalidated; the email link no longer works |
| Delete the document or folder | Access ends with the resource (it lands in your bin; see Recycling Bin) |
The change propagates in realtime. The other person’s tab updates the moment the row is gone (the dialog and library lists subscribe to the same realtime channel).
What it doesn’t do (yet)
| Missing | Notes |
|---|---|
| Bulk invite from a list of emails / CSV | Not in v1 — invite one address at a time |
| Domain-wide invites (e.g., everyone at @acme.com) | Not in v1 (see Domain capture for related concept) |
| Approval workflows / role requests | Not in v1 |
| Comment-only role distinct from Read | Comments require Write |
| Re-send invite email | Cancel + re-invite has the same effect |
| Expiration on invites themselves | Invites stay valid until accepted, canceled, or the resource is deleted |