# Scopes

> The whole organisation, a development project or a repository: where a member’s role applies and what happens where scopes overlap.

A permission is granted not “in general” but **for a scope**. The scope answers the question “where”: the whole organisation, one development project or one repository. The role answers the question “what”.

## Three kinds of scope

| Scope | What it covers | When it fits |
| --- | --- | --- |
| **The whole organisation** | All the organisation’s development projects and repositories — those that exist now and those that appear later. | Staff employees, the tech lead. |
| **Development project** | The project itself (its tasks, reviews, audits, conversations, research) and **all its source repositories**, including those added to the project later. A [space](/en/docs/quickstart/space) is the same kind of scope: its conversations, research and entries. | A developer on one team, a contractor on one project; a product manager in their space. |
| **Repository** | One repository: questions about the code (“Ask”) and research on it. Tasks are run in projects, so a standalone repository gives no tasks. | An auditor or consultant who only needs the code. |

Outside their scopes a member **sees nothing**: no projects or repositories in the switcher, no tasks, no conversations. A direct link to someone else’s project opens “project not found”.

## Several scopes

One member can have several grants — one per scope. This is how real situations are put together:

- Maintainer in the `shop` project and Contributor in the rest of the organisation;
- Contributor in the `shop` and `bot` projects, but not in `internal`;
- Contributor in the whole organisation, plus the “Run audits” permission turned on individually only in the `bot` project.

Two scopes of the same kind pointing at the same thing (for example, two grants on the `shop` project) are not allowed — the editor will not let you save them.

## When scopes overlap

The **narrowest** scope covering the resource applies: a repository is narrower than a project, a project narrower than the organisation.

| Member’s grants | Task in the `shop` project | Task in the `bot` project |
| --- | --- | --- |
| Contributor on the organisation | Contributor | Contributor |
| Contributor on the organisation + Maintainer on `shop` | **Maintainer** | Contributor |
| Maintainer on the organisation + Contributor on `shop` | **Contributor** (narrowing) | Maintainer |

A narrow scope can both widen and narrow permissions — this lets you give a person broad access and carve out one exception separately.

## How scopes relate to repositories

Access to the organisation’s repositories is granted **automatically** from the grants: a member with a “project” scope gets access to the project and all its sources, with a “repository” scope — to that one repository, with an “organisation” scope — to all of them. When a new source repository is added to a project, members with a grant on that project get access to it on their own, without any action from the owner. There is no need to set up repository access separately.

## What to do if a member sees the wrong things

- **Does not see a project** — check that their grants include the “whole organisation” scope or exactly this project (not just one of its repositories).
- **Sees the project but cannot act** — the scope is there but a permission is missing: open “Permissions” → “Advanced” and see which switch is off.
- **Sees too much** — they have a grant on the whole organisation; replace it with grants on the projects needed.