Документация Баунс

The three workspace roles — member, admin, owner: who can do what, how to invite people, and what happens when someone leaves.

Everyone in a workspace has a role, and the role decides what they can do. There are three, ascending: member, admin, owner.

The daily work is the same for all three: filing issues, writing comments, handing work to agents, belonging to teams. The differences start where management does — the roster, the workspace settings, and access.

The three roles

Member — does the work. Files and runs issues, comments, hands work to the agents available to them. Invites nobody and configures nothing at the workspace level.
Admin — all of that plus management: invites and removes people, changes roles (owners aside), configures agents and the machines, creates credentials, turns sections on in Features.
Owner — all of that plus authority over the workspace itself: appoints other owners, and can delete the workspace.

Rights by role

Action	Member	Admin	Owner
File issues, comment, hand work to agents	✓	✓	✓
Invite people and remove them from the workspace	✗	✓	✓
Change a member's or an admin's role	✗	✓	✓
Configure the workspace, credentials, runtime, Features	✗	✓	✓
Appoint an owner or change an owner's role	✗	✗	✓
Delete the workspace	✗	✗	✓

Appointing an owner

One rule: only someone who already holds the top role can grant it. An admin promotes and demotes members and other admins, but can neither appoint an owner nor touch an existing one. Which makes admin a role about running the place day to day, not about full control of it.

Agents have no role — they are not part of this hierarchy. An agent has an owner and a visibility: a workspace-level agent is available to everyone, a private one only to its owner and the workspace's admins and owners. See Agents.

Inviting a member

Open Settings → Members and press Invite member.
Give the email, pick the role — admin or member — and the team they will join (the default team is pre-selected).
They get an email with a link, open it, sign in with the emailed code, and accept the invitation.

What is worth knowing up front:

No account is needed beforehand — it is created on their first sign-in through the invitation.
An invitation is valid for 7 days. An expired link cannot be revived; send a new one.
An invitation can be revoked before it is accepted, from the pending list. The recipient, in turn, can decline it.
Nobody is invited straight to owner — you invite a member or an admin, and a current owner promotes from there.
Joining the workspace is joining a team: the one chosen on the invitation, or the default one.

Removing a member

An admin or an owner can remove a member; anyone can leave on their own. What happens then:

Access ends immediately — until a new invitation, they no longer see the workspace.
Their work stays. Issues, comments, and everything else they created remain in the workspace.
Leaving the workspace leaves all of its teams, in one operation.
A team leader has to be replaced first. If the person leads a team, the removal is refused with a request to hand leadership over — the platform never reassigns a leader on your behalf.
The last owner cannot be removed. Appoint another owner first.
Their agents stay in the workspace. An agent's owner cannot be changed, but admins and owners can still configure it, assign it, or archive it.

Before offboarding someone who had their own agents and integrations, check two things: who takes over the teams they led, and which agents are left unattended. Both are settled before the removal — afterwards, some of it is admin-only work.

The members list

The Members page shows people and agents together, with All / People / Agents filters. For a person it shows the role and the teams; for an agent, its owner. Roles and invitations are managed in Settings → Members, and the same data is available through the CLI.

Teams — grouping people and agents, and who leads a team.
Issues — what members work on.
Workspaces — what else an admin configures.

Members and roles