Workspaces & Projects¶
Workspaces¶
A workspace is the top-level container for everything you do in Doable. Every project, integration, AI key, and member belongs to exactly one workspace.
Personal vs team¶
- Personal workspace: created automatically on signup. Just you.
- Team workspace: create from the dashboard ("New workspace"). Invite members by email; they receive a link to join.
First-run wizard: Environment, Knowledge, Integrations¶
The first time you land in a fresh workspace (right after signup, or the first time you open a team workspace someone invited you to), Doable opens a short wizard. It's three real steps plus a "done" screen, and it takes under two minutes.
| Step | What it asks | Why |
|---|---|---|
| Environment | Workspace name, an emoji icon, and a colour chip (8 colours) | Names and colours show up in the switcher so a person in three workspaces can tell them apart at a glance |
| Knowledge | A free-text "what the AI should know about this workspace": brand voice, conventions, links to internal docs | Every AI request in this workspace is augmented with this context |
| Integrations | One-click connect for the most-used services: GitHub, Slack, Gmail, Google Drive, Notion, Linear, Figma, Jira | The OAuth round-trip uses the platform-managed apps your platform admin registered; you don't need your own client IDs |
| Done | A summary screen; you can re-open any of these from Workspace Settings later |
You can skip any step (use the "Skip for now" link) and edit everything later under Workspace Settings → General / Knowledge / Integrations. The wizard only opens automatically the first time per workspace.
Workspace settings¶
From the workspace switcher (top-left), open Workspace Settings:
| Tab | Purpose |
|---|---|
| General | Name, slug (URL part), avatar, time zone |
| Members | Invite, change roles, remove |
| AI | Default model, providers, API keys, modes, tools, credit limits |
| Integrations | Connect Slack, Notion, Linear, GitHub, Stripe, … |
| Connectors | MCP servers: give the agent access to private knowledge |
| Skills | Reusable prompts/snippets your agents will use |
| Environments | Build environments (Node version, env vars) |
| Audit | Every tool call the agent has made |
| Billing | Plan, credits, invoices |
Switching workspaces¶
The switcher in the top-left lists every workspace you belong to. Click to switch; your URL changes to that workspace's slug.
Projects¶
A project is one app/website. Projects live inside workspaces and can be organized into folders.
Creating a project¶
From the dashboard, click New project. You have three paths:
- Prompt-first: type “A landing page for a coffee shop”. Doable picks a template and starts the AI's first task.
- Template-first: pick from Blank, Landing page, Blog, Portfolio, SaaS dashboard, E-commerce store, Todo app.
- Import: clone from a GitHub repo (requires GitHub integration).
Folders¶
Click New folder in the dashboard sidebar. Drag projects between folders to organize. Folders are workspace-scoped.
Visibility¶
Projects have three visibility levels:
| Level | Who can view |
|---|---|
| Private | Only the workspace members you grant access to |
| Workspace | All workspace members |
| Public | Anyone with the link, listed under Discover |
Set under Project → Settings → Visibility.
Sharing & collaboration¶
Open the Share menu in the editor:
- Invite by email: adds the user to the workspace if they aren't already, and grants project access.
- Anyone with the link: generate a read-only or edit link.
- Live presence: see who is currently in the project (cursor + name pill).
Versioning¶
Every meaningful change creates a Git commit in the project's hidden Git repo (PROJECTS_ROOT/<id>/.git). View under Project → History:
- Browse commits with diffs.
- Roll back to a previous version (creates a new commit).
- Tag a "milestone" you can return to easily.
Deleting¶
Owners can delete projects from Project → Settings → Danger zone. Deletion is soft by default; a hard-delete option (irreversible, also wipes the project filesystem) is available to workspace owners.
Personal vs workspace AI scope¶
Doable splits AI account ownership into personal and workspace scopes. This applies to both GitHub Copilot accounts and AI provider keys (Anthropic, OpenAI, etc.).
Personal scope¶
A personal credential is owned by exactly one user. Only that user can see it, use it, or modify it. No other workspace member, including workspace admins and owners, can view the key material or even enumerate personal rows that belong to someone else.
Personal credentials are managed under Account → AI in the top-right user menu. Any workspace member can add personal credentials; no admin approval is required. Typical use cases: personal API keys billed to your own account, or a GitHub Copilot seat you own independently of your team.
Workspace scope¶
A workspace credential is shared across all workspace members. It is configured by workspace owners or admins under Workspace Settings → AI. All members can select workspace credentials in the model picker when working on any project inside that workspace.
Workspace credentials are the right choice when your organisation has a shared API contract or an enterprise GitHub Copilot seat that should be available to the whole team.
When to use which¶
| Situation | Recommended scope |
|---|---|
| Experimenting with a new model on your own budget | Personal |
| Team-wide access billed to the organisation | Workspace |
| A GitHub Copilot individual seat you pay for yourself | Personal |
| A GitHub Copilot enterprise seat shared by the team | Workspace |
| You want admins to be able to audit usage | Workspace |
Switching between them¶
In the editor's model picker (top of the chat panel), you can choose from both personal and workspace credentials side by side. Each entry is labelled with its scope, for example "Anthropic (personal)" or "OpenAI (workspace)", so it is always clear which budget a conversation will draw from.
Your current selection is saved as a personal preference per workspace, so switching workspaces restores the last credential you used there.
Privacy guarantee¶
Note
Even a platform admin viewing the admin dashboard cannot read the API key material or the GitHub login of another user's personal credential. The admin dashboard exposes only non-sensitive metadata (provider name, scope, and the internal owner_user_id). Key secrecy is enforced at every layer: Row-Level Security policies in PostgreSQL, scope-aware authorization checks in the API, and encryption at rest for key values.