# Members and permissions

> Who can do what in the organisation: the owner, the Contributor and Maintainer roles, scopes and fine-grained permissions.

Buff is a team tool: people with different responsibilities work in one organisation. Some set tasks, some make decisions on other people’s tasks, some only read. Permissions describe this precisely and predictably: each member sees only what they are meant to see and cannot press what is outside their role.

The setup lives in [Settings](/en/docs/settings) → choose the organisation → the **“Members”** section. Only the **organisation owner** can change the team and its permissions; other members see the team and each person’s permissions but cannot edit them.

_Illustration: The “Members” section: a description of the roles, the invitation form with a role and a scope, the list of members with their permissions._

## Three concepts

A member’s permissions are made up of three things — enough for a team of two and for an organisation with dozens of projects.

| Concept | What it is | In detail |
| --- | --- | --- |
| **Role** | A ready-made set of permissions: a **Contributor** runs their own tasks, a **Maintainer** also decides on other people’s. The owner stands above the roles and can do everything. | [Roles](/en/docs/teams/roles) |
| **Scope** | Where the role applies: the whole organisation, one development project (or space) or one repository. Outside the scope the member sees nothing. | [Scopes](/en/docs/teams/scopes) |
| **Permission** | An atomic permission for one action — “approve the formulation of other people’s tasks”, “approve and publish PRs/MRs”. A role is a set of them that can be adjusted one by one. | [Permissions reference](/en/docs/teams/permissions) |

The combination “scope + role + individual adjustments” is called a **grant**. A member can have several grants — for example, Maintainer in the `shop` project and Contributor in the rest of the organisation.

## Where to start

1. **Invite a member** — login or email, role and scope in one form. For most people Contributor on a project is right: the person runs their own tasks and sees what colleagues are doing. See [Managing members](/en/docs/teams/manage).
2. **Give the tech lead Maintainer** — they will approve other people’s formulations, send work back for rework and publish PRs/MRs.
3. **Fine-tune** if the role does not fit exactly: the **“Permissions”** button → “Advanced” → the switches. For example, a contributor who reviews can be given “Resolve and dismiss findings — other people’s tasks” without being made a Maintainer.

Ready-made setups for typical teams are in [Scenarios](/en/docs/teams/recipes).

## How it works

- **Reading is shared, actions follow permissions.** Within their scope a member sees the tasks, reviews, “Ask” conversations and research of all colleagues. What differs is only what they can *do*.
- **Own and other people’s.** Most actions on a task exist in two variants — for own tasks (ones the member opened themselves) and for other people’s. A Contributor gets “own”, a Maintainer gets “other people’s” too.
- **The server checks.** The interface does not show unavailable buttons, but the server makes the decision on every action. If the owner narrowed the permissions while the page was open, the action is still refused — with an explanation. See [What a member sees](/en/docs/teams/what-members-see).
- **The owner is outside the settings.** The owner’s permissions cannot be edited: the owner invites and removes members, assigns permissions, and manages billing, the plan, models and connectors.