Workspaces and tenancy

A workspace is the container for everything you do in Disco Parrot. Your projects, your initiatives and plans, the people on your team, the roles that decide who can do what, your secrets, your sandboxes, and your connected repositories all belong to one workspace and never leak into another. When the product talks about a "tenant," this is what it means: a workspace is a tenant, and a tenant is the line that separates your organization's data from everyone else's.

Most of the time you work inside a single workspace and never think about the boundary, which is the point. This page is about the boundary itself: how to create a workspace, move between the ones you belong to, name and brand it, decide who owns it, let the right people join on their own, and take one down. For what Disco Parrot is and how a workspace fits the larger picture, read what is Disco Parrot and how Disco Parrot works.

What a workspace holds

Everything in Disco Parrot is scoped to one workspace. There is no shared pool of projects that several workspaces dip into, and no global member list that spans them. Each workspace carries its own copy of every kind of record, partitioned underneath by a tenant identifier so that one workspace can never read another's data.

That isolation is not a feature you turn on. It is how the platform is built: a request arrives carrying the workspace you are acting in, and every read and write is filtered to that workspace before it touches storage. Switching workspaces is not a filter you apply on top of a shared view; it is a different boundary entirely, which is why switching reloads the whole application rather than re-querying the same screen.

The practical consequence is that the same person can belong to several workspaces with a different role in each. You might own the workspace your team works in, sit as a plain member in a partner's, and have read-only access to a third. Your account is one thing; your standing is decided per workspace.

Create a workspace

You do not start from nothing. The first time you sign in, Disco Parrot makes sure you land somewhere. If your organization has claimed your email domain, you are placed into that workspace automatically; otherwise the platform creates a personal workspace named after you (Your Name's Workspace), with you as its owner. Creating more workspaces from there is a deliberate act.

Anyone with an account can create a workspace. From the user menu in the top right, choose Create new workspace, give it a name, and confirm. The moment it exists, you are its owner, the single person with the final say over it, and a workspace membership is created tying your account to it as role:Owner.

A fresh workspace starts empty. There is no sample project and no seeded data; it is yours to fill. The application reloads into it so that every tenant-scoped surface (chat, sandboxes, profiles, projects) comes up pointed at the new workspace rather than the one you were just in.

You can belong to as many workspaces as you are invited to, but the number you can own is capped. Owning a workspace carries the load-bearing responsibilities: the vault, the billing relationship, the final authority. The cap keeps a single account from accumulating more of those than it can answer for.

Switch between workspaces

The workspaces you belong to are listed in the user menu under a Workspaces heading, each one a row you can select. Choosing a different one switches you into it, and because the workspace is the data boundary, the application reloads so everything comes up scoped to where you now are.

If you have been invited to workspaces you have not joined yet, the menu shows a Pending invitations row with a count, so an invitation waiting for you is visible from the same place you switch workspaces. Accepting one is covered in members and invitations.

Rename and brand a workspace

A workspace's name and look are editable from Settings → Workspace, on the General section. You can change the workspace name at any time, and you can give the workspace an icon from a small set of glyphs so that teams who run several workspaces can tell them apart at a glance. Both are saved with a single Save, and both require the tenant.update permission, which is why the controls are read-only for members who do not hold it.

The created date and the workspace's identifier sit beneath the form. You rarely need the identifier day to day, but it is the unambiguous name for the workspace when you are talking to support or reading an audit entry, so it is always in reach.

Plan, usage, and AI spend

The same settings page carries a Plan and Usage section: a link into your plan limits, active usage, and included capabilities, and a switch for AI spend tracking that turns the workspace's AI usage metering on or off. Pausing it stops the metering, not the work and not the billing. The substance of plans, entitlements, and how usage is measured lives in plans and usage and usage metering and quotas; here it is enough to know the controls sit on the workspace settings page, behind the same tenant.update permission as the rest of it. The toggle exists because metering is meant to be observable and pausable on its own, so an administrator can quiet the meter during a known burst of usage without it implying that any work or billing has stopped.

Who owns a workspace

Every workspace has exactly one owner. Ownership is not a role you can hold several of; it is a single seat, recorded directly on the workspace, that carries the powers no one else has: deleting the workspace, and being the last line of authority over it. An owner is also an administrator, so the owner can do everything an admin can, plus the things reserved for the seat. Ownership is distinct from authorship: the workspace records who created it, and that record stays put when ownership moves, so a transfer never rewrites where the workspace came from.

Because the seat is singular and load-bearing, the owner cannot leave the workspace the way a member can. Leaving would strand the workspace with no final authority, so the only ways out for an owner are to transfer ownership to someone else first or to delete the workspace outright. A member who tries to remove the owner, or strip the owner's role, is refused for the same reason.

Transferring ownership hands the seat to another member, and it happens in three moves so that the workspace is never left without a clear authority in the middle. The current owner steps down to administrator, the chosen member is raised to owner, and the ownership seat on the workspace itself moves to them. The new owner must already be an active member of the workspace before the transfer can begin, and the transfer is gated by members.manage, so it is an administrator-level action rather than something any member can trigger.

Let people in by their email domain

For a team that all shares an email domain, inviting people one at a time is busywork. A workspace can claim a domain so that anyone who signs in with an email on that domain is placed into the workspace automatically, with no invitation to send and no link to share. It is the closest thing to "everyone at our company lands in the right workspace" without standing up a full identity provider.

Claiming a domain is deliberate, because letting people in by their email is a real grant. Three things gate it.

First, the domain has to be yours. Public email domains (gmail.com, outlook.com, yahoo.com, icloud.com, and other common consumer providers) cannot be claimed, because a shared public domain does not identify a single organization. You can only claim a domain you actually use: the person claiming it must have a linked login whose email is on that domain, so no one claims a domain they have no presence on. And a domain belongs to one workspace at a time. If another workspace has already claimed it, the attempt is refused.

Second, you have to prove you control it. Claiming a domain puts it in a pending state and gives you a DNS TXT record to add to that domain: a record named _prototype-studio-verify.<your-domain> carrying a one-time verification token. Once the record is live, Disco Parrot looks it up, confirms the token matches, and marks the domain verified. This is the same mechanism every serious service uses to prove domain control, and it means no one can claim a domain they cannot edit DNS for.

Third, auto-join is a switch you turn on, and it is a plan capability. A verified domain does not let anyone in until you enable auto-join for it, and auto-join is gated by an entitlement on your plan, because automatic membership is the kind of control an organization adopts deliberately rather than a default every workspace runs.

With it on, the rule is specific. When someone signs in with Microsoft using an email on your verified, auto-join domain, and they are not already a member, they are added as a plain member and dropped straight into the workspace. They arrive with no elevated access; an administrator shapes their role from there. Auto-join acts on sign-ins from that point on; it never sweeps in accounts that already exist, and turning it off or removing the domain claim stops new sign-ins from joining without removing anyone who already joined. Microsoft sign-in carries this because organizations run their workforce identity on Microsoft Entra, which is where domain-based membership belongs.

The result is that the people who belong in your workspace arrive in it the first time they sign in, and the people who do not never see it. For how that same moment looks from the person signing in, see authentication and identity.

The per-workspace secret vault

Each workspace has its own dedicated secret vault, a per-tenant Azure Key Vault that holds the workspace's secrets in isolation from every other workspace's. The vault has a status you can see, provisioning while it is being created, ready once it is, or failed if creation did not complete, and the secrets surface reports it so you always know whether the workspace's vault is standing.

You manage the secrets that live in it on the secrets page; this page only notes that the vault is real, per-workspace, and the reason a secret in one workspace is unreachable from another. Secrets live in the vault, so storing or reading them waits on it being ready, while the rest of the workspace runs regardless. If a vault ever reads failed, that status surfaces on the secrets page. When a workspace is deleted, its vault is taken down with it.

What happens to your work in flight

Because the workspace is a hard boundary, switching is not a view change you can do mid-thought without consequence. When you switch, the application reloads, and every tenant-scoped surface, your chats, your sandboxes, your project records, comes up pointed at the workspace you moved into. The work you had open in the workspace you left is not gone; it belongs to that workspace, and you see it again when you switch back.

A running sandbox makes this concrete. A sandbox is launched inside the workspace whose work it serves, and it stays the property of that workspace. It keeps its own lifecycle, running or idling on its own clock no matter which workspace you happen to be looking at, and it is not visible or reachable from another. When Priya Patel jumps from her team's workspace into a partner's read-only one to check something, the agent run she left going on her own team's plan keeps running where it was launched; the partner workspace shows her only what belongs to it. Switching never reaches across the boundary, which is the whole point of having one.

Delete a workspace

Deleting a workspace is permanent, and only the owner can do it. It lives in a Danger zone at the bottom of the workspace settings, shown only to someone who holds the tenant.delete permission, and it asks you to type the workspace's name before the button arms, so deletion is always a deliberate act and never a mis-click.

When a workspace is deleted, the platform does the cleanup that has to happen: it removes the workspace's domain claims, takes down its secret vault, and clears out any persistent sandbox storage the workspace held, before removing the workspace and every membership in it. If sandbox storage is still in use and cannot be cleared, deletion reports that rather than leaving orphaned disks behind, so you can release those sandboxes and delete again. Everyone who was a member is no longer a member; their accounts are untouched, and they keep every other workspace they belong to.

Why workspaces work this way

The easy way to build a multi-team product is one big database with a column that says which team a row belongs to, and a hope that every query remembers to check it. That works until the one query that forgot, and then one customer is reading another's data. Disco Parrot does not rely on remembering. The workspace is the boundary at the storage layer, every record partitioned by its tenant, so isolation is the default state rather than a check that has to fire on every request. Switching workspaces reloads the application because the boundary itself changed.

The single-owner model is the other deliberate choice. Plenty of systems let ownership blur across a group of admins, and then no one is quite accountable when the question is "whose workspace is this." A workspace has exactly one owner, recorded on the workspace itself, holding the powers that should belong to one person: the billing relationship, the vault, the authority to delete. Ownership can move, but it moves in a clean hand-off that never leaves the seat empty, and the owner cannot walk away from it. Accountability has a name.

Domain auto-join is where those two ideas meet the real world. A growing team does not want to invite forty people by hand, and a security owner does not want anyone who guesses a workspace name to wander in. So joining by domain is real, but it is fenced: the domain must be one you control, you must prove that control through DNS, public domains are refused, and turning the gate on is a plan-level decision rather than a default. It is single sign-on's most useful property, the right people land in the right place automatically, without the weight of a full identity-provider integration, and with the proof of control that keeps it honest.

For a team lead, a workspace is the unit you actually run. Everything your team touches lives inside it, you decide who is in it and what they can do, and when your whole company shares a domain you can let them in by signing in rather than chasing invitations.

For an engineer, the boundary is why your standing can differ across workspaces and why nothing you do in one bleeds into another. You can own a personal sandbox workspace, contribute in your team's, and read a partner's, all from one account, and the role you hold is decided per workspace.

For a workspace owner, the model puts the load-bearing powers in your hands and keeps them accountable. You hold the vault, the plan, and the delete button; you cannot accidentally strand the workspace by leaving; and handing it on is a clean, confirmed transfer rather than a fade-out.

For the person who owns identity and security, this is the answer to "who can get into our workspace, and how do we prove it." Membership is explicit or it is by a domain you have verified through DNS, public domains cannot be claimed, automatic membership is a deliberate plan capability, and deleting a workspace takes its secrets and storage down with it. The boundary is enforced where data lives, not where a query happened to remember it.