Team members, roles, and permissions

Projects are shared with your team through invitations. Each member holds one of three roles.

The three roles

Roles are a fixed system enum — they cannot be customized.

What each role can do

MEMBER can do the everyday work: view reports and tasks, comment, move tasks across the board, and connect an AI assistant, by signing in or with their own MCP tokens. This covers most of what a team does.

ADMIN can do all of that plus configuration:

• Invite, remove, and manage members

• Create and revoke widget keys

• Create and revoke release tokens for source map uploads

• See every member's MCP tokens and revoke any of them

• Configure integrations

• Create and manage webhooks

• Edit project settings

• Manage board columns

• Delete tasks and reports

OWNER can do everything an ADMIN can, plus two things reserved exclusively to them:

• Delete the project

• Change member roles

That second one is worth noting: promoting someone to ADMIN, or demoting them, is an OWNER-only action. An ADMIN can invite and remove people but cannot change what role anyone holds.

The OWNER also cannot be removed or have their role changed while they hold the role — ownership must be transferred first.

Inviting people

An OWNER or ADMIN invites by email. The invitee receives an invitation they can accept or decline, and an invitation has one of four states: PENDING, ACCEPTED, DECLINED, or REVOKED.

Pending invitations can be resent if the email was missed, or revoked if sent in error.

Inviting someone who does not yet have a BugDump account works fine — the invitation is waiting for them, and is accepted automatically once they register with that email address.

Member limits

Members per project are capped by the project owner's plan:

The limit counts accepted members. Hitting the cap produces an error on invitation, so remove someone inactive or upgrade to add more.

The limit follows the owner's plan, not the invitee's. Members do not need their own paid plan to join a Pro project.

Notifications per member

Every member gets an in-app notification when a report arrives, and an email too when Email notifications is on under account settings → My notifications.

This matters on a team of any size. Everyone being emailed about every report is how a team learns to ignore notifications. Leave email on for whoever is triaging and let everyone else turn it off — they will still see the reports in the dashboard.

Email notifications about new reports are on every plan, Free included, with no monthly limit. A member gets one only with a verified email address and Email notifications switched on in their account settings, and at most one every five minutes.

Every member is also told about captured JavaScript errors: a new error, and an error that comes back and reopens its task, in the app and by email, on every plan. Error emails go out at most once every five minutes per person. See Working with captured errors.

On the Team page, each member has a New errors switch, on by default, and a New reports switch next to it for new widget reports. Members change their own switches; OWNERs and ADMINs can change anyone's.

Members also hear about the tasks they're involved in: a task assigned to them, or one they created, commented on or are named in a member property of, when it gets a comment, changes status or has a property changed. Nobody is told about their own changes. See Task notifications: who hears about a change.

Transferring ownership

Ownership can be transferred to another member. Use this when the original creator leaves the team — otherwise the project keeps a role nobody can exercise.

The receiving user must already be a member of the project.

MCP tokens follow the member

Every member, whatever their role, can create personal MCP tokens on the project's MCP server page. A token acts as the member who created it: it sees what they can see, and every change it makes is recorded under their name with a via MCP label.

A MEMBER sees and revokes only their own tokens. OWNERs and ADMINs see every member's tokens on the same page and can revoke any of them.

Removing someone from the project revokes all of their tokens at once, so a departing member's AI client stops working the moment they leave, with nothing to hunt down.

A member can also connect Claude, ChatGPT or VS Code by signing in. That connection acts as them in every project they belong to, with the role they hold in each, and its changes carry the same via MCP label. It is listed in their own account settings → Security → Connected apps, and removing them from a project cuts it off from that project. See Connecting Claude, ChatGPT or VS Code to BugDump.

Roles are per project

A role applies to one project only. Someone can be OWNER of one project and MEMBER of another. There is no organization-level role above projects.

Choosing roles well

Give ADMIN sparingly. The dividing line is meaningful: an ADMIN can configure integrations and webhooks, which send report data outside BugDump, and can revoke other members' MCP tokens.

MEMBER is the right default for most people. It covers everything needed to triage and fix bugs, and nothing that changes how the project is wired up.

See also

• Task notifications: who hears about a change

• Plans, limits, and usage

• Managing API keys safely

• Using BugDump with Claude Code (MCP)