Sharing & roles
Invite humans by email. Mint API keys for agents. Everyone lands in the same workspace with a specific role. Every action is attributed to the principal that made it.
Four roles
Inviting a human
Two ways depending on whether you want them in the whole team or just one workspace:
- Workspace-only (this page). Open the workspace, click Share top-right, enter the email, pick a role, send. They get a magic-link email and land in this workspace. Use this for outside collaborators — including people who already have their own team in Dock. Their team isn’t merged with yours; they just gain access to this one workspace at the role you pick.
- Whole team. Open Settings → Users and use Invite user. They become an org member and get access to every shared workspace at once. See the Teams guide for the full flow, including open join links.
Their agents come with them.Whichever path you pick, the invitee’s signed agents inherit the same access at the same role — even when the invitee lives in a different team. Trusting a person means trusting their tools. You manage the person; they manage their fleet in their own team. If you remove them or downgrade their role, every agent they had auto-enrolled on this workspace follows in the same operation. See the Teams guide for the full inheritance + cascade rules.
Inviting an agent
Agents authenticate with Bearer tokens rather than magic links.
- In the Share modal (or Settings → API keys), name the agent and pick a role + workspace scope.
- Dock returns a one-time secret
dk_.... Copy it, it won't be shown again. - Give the secret to the agent. Every request it makes carries
Authorization: Bearer dk_....
Agents have their own identity in the audit log. Every row they create shows up as Argus added 3 rows, not API integration added 3 rows.
Key scopes
- Workspace-scoped (default): key works against one workspace. Revocation limited to that workspace.
- Org-scoped: key can see every workspace you own. Convenient for trusted meta-agents; avoid for third-party agents.
Revoking access
- Humans: Share modal → click Remove next to their name. They lose access immediately; their past writes stay attributed to them in the audit log.
- Agents: Settings → API keys → Revoke. The next request returns
401.
Visibility
Visibility controls who can read a workspace. Edit access is always gated on membership — this setting only widens reads. Pick per workspace in the Share modal; flip the default for new workspaces org-wide in Settings → Organization.
Critical rule: visibility never grants write access. Even on a public workspace, only explicit members with the right role can edit. If you want someone to edit, invite them — a link share is never a license to write.
Org-level default
One org-wide setting controls what new workspaces default to. Two values:
- Private — every new workspace starts locked down. You flip specific ones to shared when you want to.
- Shared within org— every new workspace is visible to all teammates by default. Best for small teams who want transparency and avoid "I can't see what others are working on" friction.
Change it in Settings → Organization → Default workspace visibility. The toggle only affects future workspaces; existing ones keep whatever you set them to.
Workspace links
Every workspace has a canonical URL: trydock.ai/{org}/{workspace}. What happens when you share it depends on the workspace's visibility:
- Private — a non-member who visits sees an invite screen. Nothing leaks.
- Shared within org — teammates see it directly; non- teammates hit the invite screen.
- Unlisted / Public — anyone with the URL reads the workspace. The dashboard URL redirects anonymous visitors to the public view at
trydock.ai/p/{org}/{workspace}. Share that URL directly when you want the clean read-only view (no sidebar, no editor chrome).
Public pages: the anonymous reader view
Flip a workspace to Public or Unlisted and Dock renders a read-only public page at /p/{org}/{workspace}. No sidebar, no Activity or Share buttons, no last-edit floater. Just the workspace title + table or doc content + a top-bar Sign-in link + a “Made with Dock” footer.
Public vs. unlisted, for SEO
- Public — indexable. The page ships
<meta name="robots" content="index,follow">, a canonical/p/*URL, JSON-LD structured data (Article for doc-mode, Dataset for table-mode), and a per-workspace OG image. Also appears in Dock's/sitemap.xmlso Google can discover it without you linking to it. - Unlisted— anyone with the link reads it, but search engines don't. The page ships
<meta name="robots" content="noindex,nofollow">and is omitted from the sitemap. Good for client deliverables, investor decks, private sharing where a search-indexed footprint is unwanted.
White-labeling (Pro + Scale)
Settings → Organization → Public page branding controls the chrome visitors see:
- Hide the “Made with Dock” footer (Pro, $19/mo or Scale, $49/mo). Flip it off, the badge disappears from every public page on this org.
- Custom logo (Scale, $49/mo). Upload an SVG or PNG, it replaces the Dock mark in the top-left on every public workspace page AND the per-workspace OG image that social unfurls use. 2 MB cap. Rendered at 24px height; aspect ratio preserved.
- Website URL (Scale). Where the custom logo links to. Opens in a new tab.
Downgrades are non-destructive: your uploaded logo + preferences stay on your org row. Public pages revert to the Dock brand until you upgrade again, at which point your setup restores as-is.
Related
- Members API — REST surface for the same flows (invite, role change, remove).
- Teams (org membership) — when to invite at the org level instead of per-workspace.
- Connect agents — agent-side identity + signed-agent inheritance.
- API authentication — Bearer keys + OAuth.
- Security — encryption, hashing, key handling.