Workspaces
What a workspace is, the difference between a shared workspace and your personal workspace, and why the personal workspace is locked (can't be renamed, deleted, or shared).
A workspace is the container almost everything in Scrydon lives inside: chats, workflows and process flows, knowledge bases, managed tables, notebooks, files, integrations enabled for that context. Every organization has one or more workspaces, and every member of an organization belongs to at least one — their own personal workspace, created automatically the moment they join.
This page explains the workspace container itself. For who can do what inside one, see Roles and permissions.
Two kinds of workspace
| Shared workspace | Personal workspace | |
|---|---|---|
| Created by | A member, explicitly (e.g. "New Workspace") | The system, automatically, the moment you join an organization |
| Named | Anything you like | Always "Personal" — cannot be renamed |
| Members | Multiple; invited or added by an owner/admin | You, and only you |
| Roles inside it | Owner, Admin, Member (see Roles and permissions) | You hold owner, but member/invite management is disabled |
| Can be renamed | Yes (owner/admin) | No — locked server-side |
| Can be deleted | Yes (owner) | No — locked server-side |
| Members can be added/removed/invited | Yes (owner/admin) | No — locked server-side |
| Visible to org admins | Yes — org admins get implicit oversight access | No — private to you, even from org admins |
| Environments | Can have multiple (e.g. dev/staging/prod) | Exactly one, named main |
| How many you have | As many as your organization creates | Exactly one per organization you belong to |
| Typical use | Team automations, shared knowledge bases, production data | Your own chats, agent memory, draft workflows, personal notes and experiments |
What the personal workspace is for
Your personal workspace is a private lane for work that is yours alone before (or instead of) it becomes something a team shares — your Chat history and agent memory, knowledge bases you're building solo, workflows you're prototyping, saved queries. You get one automatically:
- the moment you create or join an organization,
- again for every organization you're added to (one personal workspace per organization, not one global personal workspace),
- and it self-heals — if a defensive check ever finds you missing one (a race during signup, a direct database insert), it's created for you at your next sign-in.
It shows up first in the workspace switcher, visually separated from your organization's shared workspaces, labeled "Personal."
Why the name and settings are locked
The personal workspace is deliberately not meant to be managed like a shared workspace. It has no membership to invite people into, nothing to rename it to that would mean anything (it is definitionally "the workspace that belongs to you"), and deleting it would leave you without the one workspace every user is guaranteed to have.
Concretely, the server rejects these operations on a personal workspace with a
403 PERSONAL_WORKSPACE_LOCKED error:
- Rename
- Delete
- Invite a member
- Add or remove a member
The Manage workspace UI mirrors this: for your personal workspace, the name is shown as read-only text (not just a disabled input), the delete "danger zone" is hidden entirely, and the Members/Invitations tabs show a short banner explaining why those actions aren't available there. This isn't a bug or a missing permission — it's the same lock enforced visually instead of via a rejected request.
Resources inside your personal workspace are not locked — you can still create, edit, and delete your own chats, workflows, and knowledge bases freely. Only the workspace container itself (its name, its membership, its existence) is protected.
Privacy: even org admins can't see in
Organization admins normally get implicit, read-oversight access to every shared workspace in the organization — that's how governance, cost insights, and support work across teams. Personal workspaces are the one exception. An org admin's workspace switcher, workspace list, and any attempt to switch into or query another member's personal workspace are all explicitly filtered out, even though the admin's oversight bypass would otherwise grant it. Your personal workspace is private to you specifically because it isn't shared workspace content — it's yours.
If your organization ever needs to review the contents of a personal workspace for a compliance or legal reason, that has to go through an explicit, audited path — never through routine admin oversight.
What you can't do (yet)
- Multiple personal workspaces per organization — not supported. Exactly
one per
(organization, you), enforced at the database level. - Promoting a personal workspace to shared — there's no built-in "convert my personal workspace into a team workspace" flow today. If work in your personal workspace needs to become a team's, recreate or move it into a shared workspace you create for that purpose.
- Multiple environments in a personal workspace — personal workspaces get
exactly one environment (
main); the dev/staging/prod environment model is a shared-workspace feature.
Related
- Roles and permissions — who can do what inside a workspace, and how organization, workspace, and clearance combine.
- Platform admins and impersonation — how platform and organization admin roles differ, and how impersonation is scoped.