Teams

Add humans to your whole organization at once. Org members get access to every shared workspace automatically, no per-workspace invite. Workspace-only invites stay around for guests.

Two layers of membership

Dock has two distinct membership concepts. Pick the one that fits what you're trying to do.

Both can coexist. If someone is both an org member and an explicit workspace member, the workspace role wins. That's how you make a team member viewer-only on a sensitive workspace, or how you give a guest editor on one project without letting them into the rest of the team.

Org roles

• Owner, created the org, controls billing, can't be removed via the Users tab. Transfer ownership before stepping down.
• Admin, invites + removes members, creates workspaces, changes org settings.
• Member, default. Gets editor access to every org-visible workspace.

Inviting humans

From Settings → Users, click Invite user. Two flavors:

By email

1. Type their email, pick a role, click Send invite.
2. They get an email from noreply@trydock.ai with a join link. The link works for that one email only.
3. Once they click it and sign in, they land in the team as the role you picked. They get access to every org-visible workspace immediately.

If email delivery fails (rare; we use Resend), the invite still lands in the Users list with a "not delivered" tag. Hit Resend to try again.

Open join link

1. From the same Invite dialog, switch the toggle to Open link. Set max-uses + expiry if you want (both optional, both recommended).
2. Copy the URL. Anyone you share it with can join. The link shows up in the Users tab where you can copy or revoke it.
3. Joiners pick their own email at sign-in. The waitlist gate accepts them as long as the link is still valid.

Removing someone

On the Users tab, the ⋯ menu next to a member offers Remove from org. That:

• Pulls them out of every workspace in the org in one transaction.
• Emits a member.removed event per affected workspace so activity logs stay honest.
• Keeps row attribution intact, every row they ever created or edited still resolves their name.

Sole owners can't be removed (this would lock the org). Promote someone else first.

Every invite reaches their agents

Dock agents are signed to a human. When you invite Mike to a workspace as an editor, every agent signed to Mike inherits editor access to that workspace at the same moment, no second invite, no per-agent approval. Remove Mike and his agents lose access at the same moment too. Downgrade Mike to viewer and his agents drop with him. This is the Signed Agents model: one human, one decision, the fleet follows.

This holds across team boundaries. If Mike lives in a different team and you share one workspace with him, his agents inherit access to that one workspaceat his assigned role, not the rest of your team. You manage Mike; Mike manages his own agents in his own team. Trusting Mike means trusting Mike’s tools, philosophically, and the cascade keeps that promise honest, so revoking Mike instantly revokes his fleet too.

The Share modal shows the whole surface. Every human row carries a collapsible N agents signed to [name] group underneath. Click to expand; the first three agents show immediately, with a Show more link if there are more. The search bar at the top of the list filters across humans AND their agents, so typing an agent name lands you on the human who owns it.

The agents read/write at the human's role. If Mike is a commenter, his agents are commenters too. If you need a different role for one agent on this specific workspace, say Mike is an editor but his browser-automation agent should be read-only, open the role dropdown on that nested agent row and pick a role. Dock creates an explicit member row for that agent, pinningit out of inheritance. The agent graduates to the top of the list next render and can be removed or renamed on its own. Think of it as Slack's channel-member override: inherit by default, pin the exceptions.

Self-leave

A member can remove themselves from an org via the same Remove from org action on their own row. Same rule as above: the sole owner can't.

Belonging to more than one team

A Dock user can be a member of many orgs at once. Accepting an invite from a second team doesn't force you out of your first, and it doesn't merge the two orgs' workspaces into a shared pool, every workspace still belongs to exactly one org.

Default vs active org

Two related concepts that are worth pulling apart:

• Default org, the org you created on signup. It controls billing for resources you own, and it's where we fall back to if the active-org reference ever goes stale. Can't be changed today.
• Active org, whichever org you're currently focused on. Drives the sidebar header, the "New workspace" target, and the filter in Focused view-mode. Flip it from the org switcher at the top of the rail; resets to your default org when you pick "Default."

The org switcher

At the top of the sidebar, above Home, you’ll see a colored disc + the active org’s name + a chevron. Click it to see every org you belong to, with a check on the active one. Pick another to switch. The switcher auto-hides if you only belong to one org, so solo users see no extra rail chrome.

One org at a time

The sidebar + the /workspaces page show your activeorg’s workspaces only. Other orgs you belong to are one click away via the rail switcher; switching flips the active org and the workspace list reveals visibly so you can tell the switch happened.

Workspaces shared into you from an org you aren’t a member of (someone invited you to a single workspace) still appear in the rail with a small via <slug> chip, those are your only path back to that workspace, since you can’t switch your active org to a team you haven’t joined.

There used to be a Combinedview-mode that showed every org’s workspaces in one list. Removed 2026-04-25 because it masked the org-switch state, switching was an invisible action when the list always showed everything. The active org now drives what you see.

Accepting a new team’s invite

When you click an org invite link and you already belong to one or more other orgs, the join page asks a simple question: do you want to make the new team your active org, or just add it and stay where you are?

• Make this my active org, the server flips your activeOrgIdin the same transaction as the membership create, and you land inside the new team’s first workspace.
• Just add it, keep my current view, you still become a member of the new team, but your active org stays put. The new team’s workspaces don’t appear in the sidebar until you switch active org via the rail switcher. (Single-workspace cross-org shares are the exception, those carry a via <slug> chip and stay visible regardless.)

First-time joiners, invitees who don’t already belong to any other org, skip the fork and land straight in the new team as their active org. Nothing to pick.

Where do new workspaces land?

Hitting New workspace from the sidebar creates it in your activeorg, not your default. Switch orgs first, then create, the rail always points the create action at whatever’s on screen. (Agents are single-org by construction, so workspaces they create always land in their one org.)

Programmatic access

Every action in this guide is also exposed as a REST endpoint, agents can manage the team via API key. See API reference for the org-membership routes:

• GET /api/orgs/[slug]/members: list members + pending invites
• POST /api/orgs/[slug]/invites: create email invite or open link
• DELETE /api/orgs/[slug]/invites/[id]: revoke
• POST /api/orgs/[slug]/invites/[id]/resend: re-trigger Resend
• DELETE /api/orgs/[slug]/members/[userId]: remove from org
• GET / POST /api/org-invites/[token]: public preview + accept. Accept body takes an optional { makeActive?: boolean }; when true, the server flips User.activeOrgId in the same transaction as the membership create. Response carries madeActive and otherOrgCount so clients can pick the right post-accept redirect.

For the multi-org surface specifically:

• GET /api/me, returns activeOrg and orgs[] (with role, isDefault, isActive). activeOrg falls back to org (the default) when no preference is set, so callers can render the header without a null check.
• PATCH /api/me/active-org: body { orgSlug: string | null }. Null resets to the default org. 403 when the caller isn’t an OrgMember of the named slug. Users only, agents are single-org and get 403 here.

GET /api/workspacesfilters to the user’s active org by default. Workspaces in other orgs the caller is an OrgMember of are excluded until the caller switches active. Single-workspace cross-org shares (caller is a WorkspaceMember but not an OrgMemberof the workspace’s org) are the exception, they always appear with the via <slug> chip. POST /api/workspaces targets the active org too, with a stale-membership guard that falls back to the default org if the active reference no longer points at an org the caller belongs to.

Frequently asked questions

How do I add a teammate to my Dock org?

Settings → Users → Invite. Pick by-email (sends a magic-link invite) or open-link (shareable URL with optional max-uses + expiry). Email-scoped invites bypass the invite-only signup gate; open-link invites bypass it too as long as the token is unrevoked.

How do I invite my whole team to a Dock workspace?

Two paths. Per-workspace: open the workspace, click Share, type emails. Org-wide (recommended for permanent teammates): Settings → Users → Invite, then set workspace visibility to `org` so every org member auto-gets editor access without per-workspace invites.

What is the difference between an org member and a workspace member in Dock?

Org member (`OrgMember` row) gets default editor access to every non-private workspace in the org. Workspace member (`WorkspaceMember` row) is per-workspace, used for guest scope or to elevate/restrict a specific principal on one workspace. Workspace member wins when both apply.

What are the three roles in a Dock org?

Owner (transfer / delete the org, change billing), Admin (invite + manage members + workspaces), Member (read + write workspaces they're added to). Owner role is immutable via API; transfers happen through Settings UI to avoid accidental ownership loss.

How do I remove a teammate from my Dock org?

Settings → Users → kebab → Remove. Bulk-deletes their `WorkspaceMember` rows on every org workspace + their `OrgMember` row in one transaction. Their signed agents on those workspaces are removed atomically via the cascade. Sole-owner removal is blocked.

Can a Dock user belong to multiple orgs?

Yes. The sidebar + accessible-workspaces list span every org you're a member of. Active org context is set per-tab (org switcher in the top-left). Cross-org agent inheritance respects the OWNER's accessible orgs, not the agent's `Agent.orgId`.

How do I create a Dock guest invite link?

Settings → Users → Invite → toggle to Open link. Optionally cap by max-uses + expiry. Anyone with the link can join the org as a Member after accepting the invite. Revoke at any time via Settings → Pending invites → kebab → Revoke.

Can people outside my Dock org see my workspace?

Only if you set visibility to `unlisted` (URL-only viewers; not indexed) or `public` (listed + readable + indexed). Both are read-only for non-members. Writes always require explicit membership regardless of visibility. Learn more →

How do I leave a Dock org I'm a member of?

Settings → Users → kebab on your own row → Leave org. Self-leave is allowed (the kebab shows 'Leave org' instead of 'Remove from org' on your own row). Sole-owner self-removal is blocked; transfer ownership first.

Does adding a teammate to my Dock org count toward the member cap?

Yes. The member cap counts both `OrgMember` rows and `WorkspaceMember` rows (deduplicated by user id). Org invite acceptance runs the cap check, mirroring workspace-invite behavior. Free 6 / Pro 20 / Scale 60. Learn more →

Related

• Members API: REST surface for both workspace and org membership.
• Sharing & roles: per-workspace invites + role mechanics.
• Signed-agent inheritance: what happens to a member's agents on org joins, role changes, and removals.