> ## Documentation Index
> Fetch the complete documentation index at: https://docs.timetracker.in/llms.txt
> Use this file to discover all available pages before exploring further.

# Supervision scope: who you can see

> A permission says what you may do. A supervision scope says who you may do it to. Learn the five scope levels and how they control people and project visibility.

A permission and a scope are two different things, and TimeTracker checks both.

* A **capability** answers: *may you do this at all?*
* A **supervision scope** answers: *for whom?*

Priya holds `time.viewOthers`, so she may view other people's hours. Her scope
decides **whose** hours those are.

If someone tells you "I have the permission but I still cannot see it", the answer is
almost always scope.

## What a scope controls

One setting governs two things at once. This is worth reading twice, because naming
only half of it is what confuses people.

A scope decides:

1. **Which people** you can act on – their time, leave and timecards.
2. **Whether you see every project**, or only the ones you manage or are staffed on.

The people half is where the middle scopes differ. On the project half there are
really only two answers: **Workspace** scope sees every project, and **every other
scope** sees only the projects you manage or are assigned to.

Because you only see a client when you can see one of their projects, project reach
also decides which **clients** appear in your lists. There is no separate client
scope.

## The five levels

Scope is set on a role, from narrowest to widest.

| Scope               | What it covers                                       |
| ------------------- | ---------------------------------------------------- |
| **None**            | Their projects, and only their own data              |
| **Project**         | Their projects, and people on them                   |
| **Group**           | Their projects, and people in their group            |
| **Project + group** | Their projects, and people on them or in their group |
| **Workspace**       | Everything in the workspace                          |

The longer explanation of each:

<AccordionGroup>
  <Accordion title="None">
    Projects they manage or are assigned to, and nobody else's time, leave or
    timecards – even if they hold the permissions.

    This is the default for Members and Contractors. Sarah sees her own work and the
    projects she is on. She does not see what Jonas tracked.
  </Accordion>

  <Accordion title="Project">
    Projects they manage or are assigned to, plus anyone who shares one of those
    projects with them.

    Priya manages the Bluebird Website Redesign. Sarah and Jonas are both on it, so
    Priya can see and approve their time on any project they share with her.
  </Accordion>

  <Accordion title="Group">
    Projects they manage or are assigned to, plus anyone in the same
    [group](/team/groups).

    Being in a group does **not** by itself add a project. This scope widens the
    people, not the project list.
  </Accordion>

  <Accordion title="Project + group">
    Both of the above. Their projects, plus anyone on those projects **or** in the
    same group.

    Use this when a team lead runs projects and also line-manages people who are not
    on those projects.
  </Accordion>

  <Accordion title="Workspace">
    Every project and every person, with no filter.

    Use for Owners, Admins, Finance, and small teams with no meaningful split.
  </Accordion>
</AccordionGroup>

## Default scope for each role

| Role            | Default scope        |
| --------------- | -------------------- |
| Owner           | Workspace *(locked)* |
| Admin           | Workspace            |
| Project Manager | Project              |
| Finance         | Workspace            |
| Member          | None                 |
| Contractor      | None                 |
| Client          | None *(locked)*      |

<Note>
  **Two roles have a locked scope.** An Owner is always Workspace – they cannot lose
  sight of their own business. A Client is always None – the portal firewall depends
  on it. Neither can be changed.
</Note>

Every other role's scope is editable when you build a [custom role](/team/custom-roles).

## Which permissions actually need a scope

Most permissions do not care about scope. Editing a task or creating a project is
about the *thing*, not about a person.

Scope matters for the permissions that reach across people:

| Capability                | What scope limits                 |
| ------------------------- | --------------------------------- |
| `time.viewOthers`         | Whose hours you can see           |
| `time.editOthers`         | Whose hours you can change        |
| `time.submitOnBehalf`     | Whose week you can submit         |
| `time.approve`            | Whose timesheets you can approve  |
| `time.adjust`             | Whose time you can correct        |
| `time.reopenApproval`     | Whose approval you can reopen     |
| `time.remind`             | Who you can nudge                 |
| `timecard.manage`         | Whose timecards you can manage    |
| `timecard.approve`        | Whose timecards you can approve   |
| `timecard.submitOnBehalf` | Whose timecard you can submit     |
| `timecard.reopen`         | Whose timecard you can reopen     |
| `leave.approve`           | Whose leave you can approve       |
| `leave.viewOthers`        | Whose leave you can see           |
| `expense.approve`         | Whose expenses you can approve    |
| `block.manageOthers`      | Whose planned work you can change |

A capability from this list is meaningless at scope **None** – you hold the
permission but it has nobody to apply to. The role editor warns you about that
combination.

<Tip>
  Some permissions are deliberately **not** scoped. Closing a period, changing
  workspace settings and managing members are workspace-level administration, not
  per-person data access. A report is an aggregate surface – its **rows** are scoped,
  but holding `report.view` on its own implies no cross-person reach.
</Tip>

## A worked example

Northwind Studio has two client teams.

* **Priya** is a Project Manager at scope **Project**. She runs Bluebird Coffee's
  Website Redesign and Harbor Logistics' Mobile App.
* **Sarah** and **Jonas** are on the Bluebird project.
* **Ana** is a contractor on the Fenwick Legal Brand Refresh only.

What Priya sees:

| Question                               | Answer | Why                                               |
| -------------------------------------- | ------ | ------------------------------------------------- |
| Can she approve Sarah's timesheet?     | Yes    | Sarah shares a project with her                   |
| Can she approve Ana's timesheet?       | **No** | Ana shares no project with Priya                  |
| Can she see the Fenwick project?       | **No** | It is not a project she manages or is assigned to |
| Can she see Fenwick Legal as a client? | **No** | She cannot see any of their projects              |
| Can she see Harbor's tasks?            | Yes    | She manages that project                          |

Now Tom (Admin, scope **Workspace**) sees all four people and all four projects,
because his scope has no filter.

If Northwind wants Priya to cover for Ana's manager during holidays, they have two
options: add Priya to the Fenwick project, or widen her scope to include her group.

## How scope interacts with reports

A report is not exempt from scope. The report runs, but the **rows** it returns are
filtered to what you may see.

That means two people can open the same saved report and get different totals, and
both are correct. Priya's version of a "Hours by person" report shows the people in
her scope. Tom's shows everyone.

This is deliberate – it lets you share one report definition across a team without
leaking data. See [report permissions](/reports/report-permissions).

## Scope and cost are different walls

Scope decides **whose** data you see. It does not decide **which numbers** you see.

Cost rates and margin are hidden by a separate capability check
(`rate.viewCost`, `time.viewCost`). Someone can have workspace-wide scope and still
never see what people cost. See [cost rates](/rates/cost-rates).

## Permissions

| Action                | Capability    | Roles        |
| --------------------- | ------------- | ------------ |
| Change a role's scope | `role.manage` | Owner, Admin |

## Common questions

<AccordionGroup>
  <Accordion title="Why can my manager not approve someone's timesheet?">
    Their scope does not reach that person. Either add the manager to a project the
    person works on, put them both in the same group and use a group scope, or widen
    the role to workspace scope.
  </Accordion>

  <Accordion title="Can I set scope for one person instead of a whole role?">
    Scope lives on the role. To give one person a different reach, build a custom
    role for them. [Per-person overrides](/team/per-person-permissions) can only
    take permissions away, not widen scope.
  </Accordion>

  <Accordion title="Does group membership add projects?">
    No. A group scope widens which **people** you can act on. It does not add their
    projects to your list.
  </Accordion>

  <Accordion title="Why do two people see different report totals?">
    Because report rows are scoped. Each person sees the slice they are allowed to
    see. Nothing is broken.
  </Accordion>

  <Accordion title="Can an Owner lose visibility of a project?">
    No. The Owner role is locked to workspace scope precisely so this cannot happen.
  </Accordion>
</AccordionGroup>

## Related guides

<CardGroup cols={2}>
  <Card title="Roles and permissions" icon="lock" href="/concepts/roles-and-capabilities">
    The capability half of the check.
  </Card>

  <Card title="Custom roles" icon="sliders" href="/team/custom-roles">
    Where scope is set.
  </Card>

  <Card title="Groups" icon="users" href="/team/groups">
    Standing teams that a scope can follow.
  </Card>

  <Card title="Project visibility" icon="eye" href="/projects/project-visibility">
    Which projects appear in your list.
  </Card>
</CardGroup>