Members and invitations
How people get into a workspace and how you manage them once they are in. Invite by a shareable link, see who belongs, assign and change roles, count seats against your plan, and remove someone or leave, with the owner protected at every turn.
A workspace is its people. Everything else (the projects, the plans, the agents doing the work) exists so a group can get something built together. The members list is where you decide who that group is. This page is about adding people, seeing who belongs, giving them the right level of access, and removing them or stepping away when the time comes.
Members live under Settings → Members. What a member can actually do is decided by their roles, which have their own home in roles and permissions; this page is about getting people in and managing the membership itself. For grouping people to grant access to particular work, see teams.
Who belongs to your workspace
The Members page is the roster: every person in the workspace, the roles they hold, and when they joined. Each row carries the person's name and email, the roles attached to their membership shown as badges, and a relative "joined" time, with a menu on the right for the actions you are allowed to take on that person. Invitations that have not been accepted yet sit in a Pending invitations section beneath the roster, and drop off it the moment they are accepted, revoked, or expire.
Everyone who can see the workspace can see this roster, because knowing who is in the room is not a privileged act. The actions on it are another matter, and the menu only offers what your own role permits.
Invite someone
You add a person by inviting them. From the Members page, choose Invite, enter their email address, pick whether they come in as a Member or an Admin, and create the invitation. What you get back is a link: Disco Parrot does not send the email for you. It hands you a single, shareable URL to pass along however your team already communicates, in an email you write, a direct message, wherever the person will see it.
The link is deliberately careful. It carries a token that Disco Parrot stores only as a hash, so the link in your messages is the only copy of the real value and the platform never holds it in the clear. It works once: the moment it is accepted it is spent. And it expires after seven days, so a link that escapes into an old thread does not stay live forever. If a link expires before it is used, or you sent it to the wrong place, you revoke the pending invitation from the kebab menu on its row and create a fresh one. A link is never regenerated; each invitation carries its own, which is what keeps revoking clean.
Treat an invite link like a password. It works once, expires after seven days, and only the email you invited can accept it. Send it straight to the person rather than to a shared channel: until it is spent, whoever holds the link can join as the role it carries.
Two details shape who you can invite and as what. You can bring a person in only as a Member or an Admin (an administrator can grant either); the finer roles, read-only viewers, planners, the rest, are assigned after they join, from the same Members page. And the email you invite is the email that has to accept: an invitation is bound to its address, so it cannot be forwarded to someone else and used by them.
Accept an invitation
There are two ways in, and they meet at the same place. A person who clicks the link you sent is taken to sign in if they are not already, and on signing in with the invited email they are dropped straight into the workspace as the role you chose. A person who is already signed in to Disco Parrot sees the invitation waiting in their user menu under Pending invitations, with a count, and accepts it there without needing the link at all.
Either way the rule is the same: the invited email has to match the account accepting, and the invitation has to still be pending and unexpired. Accept it and the membership is created with the role the invitation carried, and the workspace becomes yours to work in. Clicking a link for a workspace you already belong to does no harm: it marks the invitation used and takes you there, without creating a second membership.
A person who has never used Disco Parrot is the easiest case of all. They click the link, sign in with the invited email for the first time, and an account is created for them on the spot. There is no separate sign-up to finish before they can accept, and nothing to configure: they land in the workspace as the role you chose, having done nothing but sign in. For where a brand-new account comes from when someone signs in for the first time, and how a verified email domain can place people without an invitation at all, see authentication and identity.
Seats and your plan
A workspace has a number of seats, set by your plan, and inviting people draws against it. The count is of active members, the people who have actually joined, so a pending invitation does not hold a seat until it is accepted, and removing someone frees theirs. When an invitation would push the active count past the cap, Disco Parrot stops it with a clear message naming your limit and your current count rather than letting you over-fill quietly.
That a pending invitation reserves nothing is deliberate, not an oversight. You can line up a whole hiring wave of invitations before the seats exist to hold them, and they convert to memberships as people accept and as your plan's seats allow, with no scramble to time each invite to the moment a seat opens.
The seat message reads "Seat limit reached. Your plan includes N active members. You currently have N active members." Because only joined members count, you can have invitations outstanding beyond your seat count; they cannot all be accepted past the cap. What your plan includes, and how to raise it, is in plans and usage.
Assign and change roles
A person's roles decide what they can touch, and you change them from the member's menu with Assign Roles. A membership can hold more than one role at once, so the dialog is a set of choices rather than a single switch: you select every role the person should have, and save. The roles they came in with, Member or Admin, are a starting point, not a fixed floor; from this dialog you set whatever combination fits what they actually do, adding a planner's reach over the roadmap, narrowing to a viewer who only reads, granting a workspace operator who manages tooling, or the admin role itself.
Tom Asare is the everyday case. He joins as a Member to get to work, and a quarter later picks up release duties. An administrator opens Assign Roles on his row, leaves Member checked, adds the workspace's custom Release Manager role, and saves. His roster row now shows both badges, and he carries the reach of both without losing what he had. Roles add up; they do not replace.
What each role grants, the full catalog of built-in roles and the custom roles you can define, is the subject of roles and permissions. Here it is enough to know that this dialog is where a person's roles are set, and that one person can wear several at once.
Remove someone, or step away
When a person should no longer have access, an administrator removes them from the member's menu, and their membership ends at once. Their account is untouched and every other workspace they belong to is unaffected; they no longer belong here, and would need a fresh invitation to return. Removing someone ends their access only: the plans, comments, and history they authored stay where they are, and the audit trail of what they did remains intact.
You can also remove yourself. Leaving a workspace is its own action, on your profile rather than a control on the members roster, and it is yours alone to take: no one can make you leave, and you cannot make anyone else leave.
Through all of this, the owner is protected. The single owner of a workspace cannot be removed, cannot have their role changed out from under them, and cannot leave the way a member can, because any of those would strand the workspace with no final authority. The owner moves on by transferring ownership to someone else or deleting the workspace, both of which live in workspaces and tenancy. An administrator who tries to re-role or remove the owner is told to use the transfer instead.
Who can manage members
Seeing the roster is open to everyone in the workspace; changing it is not. Inviting people, assigning roles, and removing members are administrator actions, carried by members.invite, members.manage, and members.remove, which the Owner and Admin roles hold. Reading the member list rides on members.read, which every role has, and leaving is a self-only action on members.leave.own that you exercise on your own membership and no one else's.
| Scope | Who holds it | What it allows |
|---|---|---|
members.read | Every role | See the member roster and pending invitations |
members.invite | Owner, Admin | Create and revoke invitations |
members.manage | Owner, Admin | Assign and change a member's roles |
members.remove | Owner, Admin | Remove a member from the workspace |
members.leave.own | Every working role | Leave the workspace yourself |
This split is the point. A member can always see who they are working with, an administrator shapes the membership, and the one thing nobody can do, to anybody, is quietly act on a person's place in the workspace without the role that allows it.
Why membership works this way
The decision that shapes everything else here is that an invitation is a link, not an email the platform sends. It looks like a small thing and it is not. It means the act of inviting never depends on deliverability, on a spam filter, on whether the platform's mail reputation is good that week; the link is in your hand the instant you create it, and you send it through a channel the person already trusts. It also means the sensitive part, the token, lives only in the message you control, stored as a hash on the platform's side, single-use and short-lived, so an invitation that leaks is an invitation that has nearly always already expired or been spent.
Seats counting only active members follows the same instinct: you should never be billed for an intention. An invitation is a hope that someone joins, and a hope does not occupy a seat. You can line up more invitations than you have room for and let the seats fill as people actually arrive, and the cap does its work at the moment of joining, where the real cost is.
And the owner protection is the quiet floor under the whole model. Membership is fluid by design, people come and go, roles change, an admin can reshape the room, but the one seat that carries final authority cannot be removed by accident or by a disgruntled administrator, and cannot be vacated without first handing it on. The result is a workspace whose membership you can manage freely precisely because the one irreversible thing is fenced off from the everyday churn.
For a team lead, this is how you build and reshape your team. Invite by a link you send yourself, bring people in as members or admins, and once they are in, give them the exact roles their work calls for. The roster is always honest about who is here.
For an engineer, an invitation is a link you click and you are in, as the role you were given. Your account is one thing across every workspace; joining one never touches the others, and leaving one is yours to do.
For an administrator, the member's menu is your console: invite, assign roles, remove, with the seat count keeping you honest about your plan and the owner protection keeping you from a mistake you cannot undo. Everything reversible is in your hands; the one thing that is not is held apart on purpose.
For the person who owns the workspace, the model guarantees that your seat cannot be taken from you, re-roled out from under you, or abandoned without a deliberate hand-off. You can let administrators run the membership day to day, knowing the authority over it stays exactly where you put it until you choose to move it.