For Workspace Admins

This guide is for workspace owners and workspace admins: the people responsible for setting up and running a team workspace in Doable. If you are managing a personal workspace for solo work, most of this still applies but several sections (member management, billing, audit) will be quiet because there is only one seat.

This guide is not the platform-admin guide. Platform admins operate the entire Doable deployment from /admin and are documented under Operations → Platform Admin. As a workspace admin you only ever see your own workspace.

Personal vs team workspaces

Every Doable account starts with a personal workspace, created automatically on signup. It is just you. No members, no invites, billed (if at all) to your own account.

A team workspace is what you create when you want to bring other people in. From the dashboard:

1. Open the workspace switcher in the top-left of the dashboard.
2. Click New workspace.
3. Give the workspace a name, slug (the URL part), and an optional emoji or color chip.
4. The workspace is created with you as the owner.

Projects, integrations, AI keys, skills, MCP servers, knowledge bases, and members all belong to exactly one workspace. There is no "move project to another workspace" shortcut yet; if you need to migrate, fork or remix the project from inside the destination workspace.

Inviting members

Open Workspace Settings → Members from the workspace switcher menu, then click Invite member.

• Enter one or more email addresses.
• Choose the role the new members will receive on accept (you can change it later).
• An invite link is emailed to each address. Anyone who already has a Doable account joins immediately on click; new users are prompted to sign up first and land on /invite/<token> to accept.

Invites do not expire automatically but can be revoked from the same dialog. Re-inviting an already-pending email is harmless; Doable updates the existing row instead of creating duplicates.

Roles at a glance

Doable defines four workspace-level roles. The actual gating rules per surface are still being firmed up; treat the table below as the intent, and verify the exact disabled-vs-hidden behavior in your environment if you are writing automation against it.

Role	Can edit projects	Can invite or remove members	Can manage Workspace Settings	Can change billing or delete the workspace
Owner	Yes	Yes	Yes (every tab including Danger zone)	Yes
Admin	Yes	Yes	Yes (every tab except ownership transfer and final delete)	Billing yes; delete no
Member	Yes	No	Read-only on most tabs	No
Viewer	Read-only (chat input disabled in the editor; no AI runs)	No	No	No

A few notes:

• A workspace must always have at least one owner. You cannot demote the last owner.
• Platform admins are a separate, deployment-wide role and are not the same as workspace owners. A platform admin who is not a member of your workspace will not appear in your member list and cannot read your private project content.
• A user can be a member of many workspaces and hold a different role in each.

Tour of Workspace Settings

Every team workspace has the same set of settings tabs, reachable from Workspace switcher → Workspace Settings. Owners and admins see all tabs; members and viewers see a read-only subset.

General

Workspace name, slug (used in the URL), description, avatar, and time zone. Changing the slug rewrites every workspace URL, so schedule slug changes carefully and tell members beforehand.

Members

Pending invites, current members, role chip per row, and per-member actions (change role, remove, resend invite). This is where ownership transfer lives; see Transferring ownership below.

AI

The central control panel for everything model-related at the workspace level:

• Default workspace model
• Provider keys (BYOK) and Provider Bridge selection
• Allowed models: restrict which models any member can pick
• Personal vs workspace scope rules

See Customizing the AI for the full tour.

Integrations

Connect Slack, Notion, Linear, GitHub, Stripe, Figma, Gmail, Google Drive, and ~620 more via the Activepieces catalog. Each integration appears in two columns: Available (the platform has registered an OAuth app or supports an API-key form) and Connected (already wired to this workspace).

Connections are workspace-scoped: every member can use them inside any project in the workspace, but they do not bleed across workspaces. Per-user personal tokens for the same provider are listed separately and are visible only to their owner.

Skills

Reusable AI capabilities (bundles of instructions, sample inputs, and tool whitelists) that any member can attach to a chat turn from the skill picker. Add a workspace-scoped skill once, and every project in the workspace gets it.

MCP servers (Connectors)

Workspace-scoped MCP (Model Context Protocol) server registrations. Adding an MCP server here gives every project in the workspace access to its tools and resources. Each entry stores the transport (HTTP / stdio / WebSocket), endpoint, and authentication. Doable is fully MCP Apps compatible: UI resources returned by MCP tools are rendered directly inside the chat thread.

Sandbox

Workspace-level allow/deny rules for what the AI can do at runtime:

• Tool default action: allow or deny for AI tools not otherwise listed.
• Network default action: same for outbound network calls.
• A per-rule editor lets you add specific patterns (with wildcards) for explicit allow or deny decisions.

The underlying API is shipped (migration 073); the per-rule add-edit UI is still being polished, so depending on your build you may see the defaults toggle without the per-rule editor. See Sandbox allow/deny lists and the broader security/sandboxing.md reference.

Knowledge bases

A markdown-driven knowledge file the AI uses as context for every project in the workspace. Paste in your brand voice, technical glossary, or onboarding checklist; the AI will pull from it on every turn. Additional file uploads and per-project knowledge are documented under the Editor guide. Per-workspace upload of arbitrary docs is TBD in current builds, so verify what you see before promising features to your team.

Billing

Plan tier (Free / Pro / Business / Enterprise), seat count, credit usage, invoices, payment method. Workspace owners can change plan and payment; admins can view and read invoices. The current month's credit burn is shown at the top with a colored bar (green ≥50% remaining, amber ≥20%, red below).

Audit

The workspace-scoped audit log. You see every AI chat session, tool call, and admin action that touched this workspace, and nothing from other workspaces. Platform admins see a wider view at /admin/audit, but it is not the same surface as this tab.

The audit log includes:

• Conversation list (project, user, mode, message count, last excerpts)
• Per-session full transcript (with PII redaction applied to logs)
• Admin action log: every member role change, every AI allocation change, every sandbox rule edit, every MFA reset

Every read against the audit log is itself audited.

Danger zone

Workspace deletion and ownership transfer. Both actions require typing the workspace name to confirm. Deletion is irreversible: projects, integrations, audit logs, and knowledge bases all go with it. Export anything you need to keep beforehand.

Promoting and demoting members

Open Workspace Settings → Members, find the row, and click the role chip.

• Owner → Admin / Member / Viewer: allowed, as long as at least one other owner remains.
• Admin → Owner: promotion any owner can perform.
• Admin → Member / Viewer: any owner can demote.
• Member → Admin / Viewer: any owner or admin can change.
• Viewer → Member / Admin: same.

A member cannot change their own role. If the only owner needs to step down, they must first promote someone else to owner.

Transferring ownership

Ownership transfer is a deliberate, two-step flow:

1. Promote the future owner to Owner. The workspace now has two owners; this is fine and is in fact the recommended steady-state for any production workspace (always keep at least two owners so a single account loss does not strand the workspace).
2. Optionally demote yourself to Admin (or any lower role) once the new owner has confirmed they can perform the workflows you used to.

There is no "transfer and demote myself in one step" button by design. Keeping two owners during the handover prevents accidental lockout.

Sandbox allow/deny lists

The Sandbox tab lets workspace admins constrain what the AI is allowed to do inside a project. There are two dimensions:

• Tools: the named AI tools (bash, edit_file, deploy_preview, …) that the AI can call.
• Network: outbound network destinations the project's runtime can reach.

For both, you pick a default action (allow or deny) and then layer rules on top. Rules support glob patterns and are evaluated top-down. The full grammar and the deeper architecture is documented in security/sandboxing.md and security/egress-firewall.md.

Platform-wide tool defaults and the per-mode tool whitelist live in the platform-admin Tools tab and override anything you do here when the platform admin is stricter than the workspace; your workspace rules cannot loosen platform-wide deny rules.

Audit visibility

You see only your workspace's events. Platform admins see a platform-wide view at /admin/audit. Every audit read is itself audited:

• When you (a workspace admin) open the Audit tab and search for "API key", that search is recorded with your user ID, timestamp, and client IP.
• When a platform admin opens any session belonging to your workspace, that view is recorded too. You can see those reads in your workspace audit log; they are not hidden from you.

This bidirectional visibility is intentional. Platform admins can see your workspace, but you can see when they did.

Deleting a workspace

From Workspace Settings → Danger zone, click Delete workspace. You must:

1. Be the owner (admins do not see this button).
2. Type the exact workspace name into the confirmation field.
3. Acknowledge the data-loss warning.

What gets deleted:

• All projects, including their Git history and file trees.
• All integrations and their credentials.
• All members' access to this workspace (their accounts are untouched).
• All audit logs scoped to this workspace.
• All knowledge bases, skills, MCP server registrations, and sandbox rules.

What does not get deleted:

• User accounts of members (they keep their personal workspace and any other workspaces).
• Platform-level audit log entries (these are retained per the platform's retention policy).
• Anything you previously exported.

Deletion is irreversible. If you only want to pause activity, demote everyone to viewer or revoke billing instead.