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 → 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.
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 |
| Scope | Where the role applies: the whole organisation, one development project (or space) or one repository. Outside the scope the member sees nothing. | 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 |
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
- 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.
- Give the tech lead Maintainer — they will approve other people’s formulations, send work back for rework and publish PRs/MRs.
- 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.
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.
- 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.