Workspaces & Membership

A workspace is lk-wiz's top-level organizational unit — every idea, post, prompt, example, and action belongs to exactly one. You can belong to several workspaces at once (a client team, an internal team, a side project), each with its own independent role, and switch between them from the sidebar.

This page describes product-facing behavior. For exact request/response shapes and error codes, see the Workspaces API reference. For programmatic access from an AI client, see Workspaces MCP tools. The underlying spec this page is based on is specs/features/workspaces.md in the repo.

Creating a workspace

Click "Create Workspace" in the sidebar or settings. All it takes is a name (up to 100 characters) and an optional description:

POST /api/workspaces

{ "name": "Acme Marketing", "description": "Q3 content calendar" }

You become the workspace's owner immediately — the create call writes the workspace and your owner membership in the same request. The new workspace shows up in the sidebar right away and becomes your active workspace.

⚠️

Despite what some internal planning docs describe, creating a workspace does not currently auto-generate a default prompt template — default_prompt_id starts out null until you (or another domain) explicitly set one.

Roles & permissions

Every member of a workspace has exactly one role, scoped to that workspace (a user can be owner of one workspace and viewer of another):

Role	Can do
Owner	Everything: rename/configure the workspace, invite and remove members, transfer ownership, delete the workspace. Exactly one owner at a time.
Editor	Update workspace settings (name, description, default prompt, publishing slots), invite new members. Cannot remove other members, transfer ownership, or delete the workspace.
Viewer	Read-only at the workspace-settings level — can see the workspace and its member list. (What a viewer can do inside posts/ideas/etc. is governed by those domains, not this one.)

These roles are completely separate from your platform-wide account role (member/admin, used for things like deleting posts mid-pipeline or the Admin console). Workspace permissions are checked purely from your membership record for that specific workspace — your global account role has no bearing here.

Who can do what

Action	Owner	Editor	Viewer
View workspace / member list	✅	✅	✅
Update name, description, default prompt, publishing slots	✅	✅	❌
Invite a member	✅	✅	❌
Remove another member	✅	❌	❌
Leave the workspace (remove yourself)	❌ (transfer ownership first)	✅	✅
Transfer ownership	✅	❌	❌
Delete the workspace	✅	❌	❌

Managing a workspace

Settings → workspace lets an owner or editor update name, description, default_prompt_id, or publishing_slots in any combination — it's a partial update, so you only send what changed.

Transferring ownership

Only the current owner can do this, and only to someone who is already a member. Include owner_id in the same update call:

PUT /api/workspaces/{id}

{ "owner_id": "user_2" }

The previous owner is automatically downgraded to editor — there's no "co-owner" state, and no automatic reassignment if an owner leaves without doing this first (which is exactly why owners can't remove themselves).

Members

Inviting someone

Owners and editors can add people by email:

POST /api/workspaces/{id}/members

{ "email": "new.person@example.com", "role": "editor" }

What happens next depends on whether that email already has an lk-wiz account:

Already a user? They're added to the workspace immediately with the role you picked.
New to lk-wiz? A pending invite is stashed against their email. The moment they sign up with that email, our Cognito post-confirmation hook automatically adds them to the workspace with the role you originally chose — no extra step for them or you.

⚠️

Note: adding a member here doesn't currently trigger a Slack DM or invite email — if you need someone to know they've been added, tell them yourself for now.

Removing someone

Any member can remove themselves (leave the workspace) except the owner, who has to transfer ownership first. Only the owner can remove other members:

DELETE /api/workspaces/{id}/members/{userId}

Removal is immediate and final — the person loses access to the workspace's data right away, though anything they authored (posts, ideas, etc.) stays put and stays attributed to them.

Deleting a workspace

Owner-only, and it's a soft delete — the workspace disappears from every member's sidebar and can no longer be opened, but nothing is actually erased. Recovering a deleted workspace (or permanently purging it) is an admin-only operation, not something workspace members can trigger themselves — see the Admin console.

Switching workspaces

The sidebar lists every workspace you belong to, with your role visible next to each. Click one to make it active — every other view (dashboard, ideas, posts, prompts, examples, schedule, actions) immediately re-scopes to that workspace. This is purely a client-side selection; there's no server-side "current workspace" concept, just whichever workspace_id the frontend sends with each request.