Workspaces

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.

Two kinds of workspace

Joining a shared workspace by invitation

An owner or admin invites you by email. The Accept invitation button in that email opens a page naming the workspace and the organization it belongs to. Sign in, or create an account, with the address the invitation was sent to, then accept: you become a member of the workspace and, if you were not one already, of its organization.

• The invitation can only be accepted by that email address. Signed in as someone else, the accept is refused.
• Not now leaves the invitation open; the link keeps working until an admin removes the invitation. There is no decline button for a workspace invitation.
• A link that was already used, or whose invitation an admin removed, opens an error page instead.

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.

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. That includes its member list: an org owner or admin can neither read who is in another member's personal workspace nor add, remove or re-role anyone there, team assignments and service accounts included. 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.

Adding people to a shared workspace or a team

The Add members dialog of a shared workspace, and the add-member picker on a team's page, search your whole organization as you type: enter part of a name or an email address and the matching members are listed, however large the organization is. When more members match than one list shows, Show more members loads the next ones. Teams are offered the same way — every team of the organization, not only the first hundred. Members who already belong to the workspace or team are not offered again.

In a large organization one search may not reach every member at once: the list can then be empty and still show Show more members. Keep selecting it until the search has looked through the whole organization.

If what you typed is an email address that matches no member, the dialog offers to send a workspace invitation to it — only once the search has looked through every member of the organization, so a colleague who is already a member is never offered as an invitation.

Listing a workspace's members, teams, service accounts and invitations

Members are listed one page at a time: POST /workspace/list-members-page takes limit (at most 100) and offset, plus an optional q to search by name or email, and returns { members, totalCount }.

The three other workspace listing endpoints — /workspace/list-team-members, /workspace/list-service-account-members and /workspace/list-invitations — return every row for the workspace in a single response. They take no cursor or limit parameter and return no next-page token.

Each listing is bounded at 500,000 rows. A workspace past that bound gets an error from the listing rather than a silently shortened list, so a response you receive is always complete. Rows come back in creation order, oldest first.

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.