> For the complete documentation index, see [llms.txt](https://help.allwage.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.allwage.com/fundamentals/users-and-employees/user-permissions.md).

# User Permissions

How AllWage decides what each user can see and change — presets, permissions and scope — and how employee data and shared setup are protected.

Every user who signs in to AllWage has their access decided by the same three things: the **preset** they're linked to, the **permissions** that preset gives, and the **scope** that limits which records they can reach. This page explains how those three layers work together, so you can give each person exactly the access their job needs — and nothing more.

It matters in any organisation, whatever its size. As soon as you have a manager who should only work with some of your employees, you want them in AllWage — capturing leave, fixing clocks, checking hours — without seeing or changing parts of the business that aren't theirs.

**What this page covers:**

* The three layers of every user's access
* The difference between employee data and shared setup
* The three permission levels, and why some areas can't be switched off
* Team scope — limiting a user to specific teams
* How team scope works day to day, including moving employees between managers

**Who this is for:**

Owners and administrators who set up and look after user access. You should already be comfortable with [employees](/fundamentals/users-and-employees/employees.md) and [teams](/fundamentals/users-and-employees/teams.md).

**Related pages:**

* [Quick Start: Who Gets Which Preset](/fundamentals/users-and-employees/user-permissions/quick-start.md) — the short version: common jobs and exactly what to choose
* [Users](/fundamentals/users-and-employees/users.md) — adding, editing and deleting users
* [Permission Presets](/fundamentals/users-and-employees/user-permissions/permission-presets.md) — the built-in presets, and building your own
* [Designing and Troubleshooting Access](/fundamentals/users-and-employees/user-permissions/designing-and-troubleshooting-access.md) — choosing a preset, Owners, and fixing access problems
* [Payroll Permissions](/fundamentals/users-and-employees/user-permissions/payroll-permissions.md) — payroll scope, payroll permissions and reports

## The Three Layers

When someone signs in, AllWage answers two questions about everything they try to do:

1. **What is this person allowed to do?** Can they only look at clocks, or fix them? Can they change a clock template, or only see it?
2. **Which records can they do it to?** Which employees, and which of their records?

The answers are held in three layers:

| Layer           | What it decides                                                | Example: a team manager                                   |
| --------------- | -------------------------------------------------------------- | --------------------------------------------------------- |
| **Preset**      | A named bundle of access. Every user is linked to exactly one. | *User — T\&A only (scoped)*                               |
| **Permissions** | For each area of the system: No access, Read or Read / Write.  | Read / Write on clocks and leave; Read on clock templates |
| **Scope**       | Which records the permissions apply to.                        | Their own team                                            |

Put together: *this person changes the clocks and leave of the employees on their team, and can read — but not change — the setup those clocks use.*

{% hint style="info" %}
You never set permissions on a person directly. What a user can do always comes from their preset. To change it, you link them to a different preset — see [Permission Presets](/fundamentals/users-and-employees/user-permissions/permission-presets.md).
{% endhint %}

## Employee Data and Shared Setup

Almost everything in AllWage falls into one of two groups.

**Operational data belongs to one employee.** In time and attendance, that's their **clocks**, **leave**, **activity items** and **hour overrides**. It changes every day, and it's what managers spend most of their time checking and correcting. Employee **documents** also belong to one employee, but they're sensitive, so they have their own permission.

**Configuration is shared setup that everyone's data refers to:** activities and their categories, teams, clock templates, custom metrics, devices, costing and WhatsApp settings. Regions, sites and geofences are shared in the same way — anyone might clock at any site.

The difference matters because of who a change affects:

* **Changing operational data affects one employee.** Adding a missing clock for an employee changes nothing for anyone else.
* **Changing configuration affects everyone who uses it.** Changing the start time on a clock template changes the hours of every employee on that template, on every team.

This is why [scope](#team-scope) follows the employee, and why managers who look after only part of the organisation usually get **Read** on shared setup, not **Read / Write**.

## Permission Levels

Every area of the system has a permission, set to one of three levels:

* **No access** — the area is hidden.
* **Read** — the user can see everything in the area, but can't add, change or delete anything.
* **Read / Write** — the user can see the area and make changes in it.

Read / Write always includes Read. You can't change what you can't see.

### Areas that are always at least Read

Some permissions can't be set to No access, because other screens rely on them. In the preset editor, No access is greyed out with a short note explaining why.

| Always at least Read                                                                           | Why                                                                        |
| ---------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------- |
| Employees, clocks, leave, activity items and hour overrides — for employees the user can see   | The hours, days and units a user sees are calculated from these records.   |
| Configuration — activities, teams, clock templates, custom metrics, devices, regions and sites | Users need to see the shared setup to make sense of their employees' data. |
| The list of users, and the permission presets they're linked to                                | Users' names and presets appear throughout AllWage.                        |
| Document categories and tags                                                                   | Other screens rely on them.                                                |

### Areas that can be switched off

**No access** is kept for areas where hiding them completely is a normal choice — such as **employee documents** and **payroll**.

### Areas that are read-only by nature

Reports have nothing to change, so they're only ever **No access** or **Read**.

### Detail permissions

Some permissions have detail rows underneath them. For example, **assigning a clock template to an employee** is its own permission under Employees, separate from managing the clock templates themselves. That's how a team manager can give a new employee a clock template without being able to change the template.

### Permissions that need another first

A few permissions only work alongside another. AllWage never switches the missing one on for you — the preset editor tells you what's needed, and the permission has no effect until you give it. The main examples are in payroll — see [Payroll Permissions](/fundamentals/users-and-employees/user-permissions/payroll-permissions.md#permissions-that-need-another-first).

## Team Scope

Scope decides which records a user's permissions apply to. In time and attendance, it's **T\&A teams** — which teams' employees the user can work with. It's always set to one of:

* **All** — every employee
* **None** — no employees through time and attendance
* **Specific** — only the employees on the teams you choose

Every employee belongs to exactly **one team**. An employee is in a user's scope when their team is one of the user's chosen teams.

### Scope follows the employee

Because clocks, leave, activity items and hour overrides belong to an employee, team scope limits all of them at once. A user who can see a team's employees automatically sees those employees' clocks, leave and hours — and nobody else's. There's nothing extra to set up. The dashboard, data review screens and reports all limit themselves in the same way.

### Shared setup isn't scoped

Configuration isn't attached to any one employee, so team scope doesn't limit it. **Regions, sites and geofences aren't scoped either** — Read / Write on sites means every site. A user's *permissions* are what stop them changing shared setup, not their scope.

### Everyone can see team names

Users can see the names of every team, because team names label employees throughout AllWage. Seeing a team's name gives no access to the employees on it.

### What None means

With T\&A teams set to **None**, a user sees no employees through time and attendance, so the time and attendance permissions apply to nobody. This is used for people who only work on payroll — see [Payroll Permissions](/fundamentals/users-and-employees/user-permissions/payroll-permissions.md).

## Team Scope in Practice

These rules apply to a user whose T\&A teams are set to specific teams.

| Situation                           | What happens                                                                                                          |
| ----------------------------------- | --------------------------------------------------------------------------------------------------------------------- |
| **Viewing and exporting employees** | They see and export only the employees on their teams.                                                                |
| **Adding an employee**              | The team is required, and they can only choose one of their own teams.                                                |
| **Moving an employee**              | Both the old and the new team must be in their scope.                                                                 |
| **Several managers on one team**    | Team scope isn't exclusive. If two users both have a team in scope, both see its employees.                           |
| **Bulk actions**                    | They can only select employees in their scope.                                                                        |
| **Reports and screens**             | Automatically show only their employees.                                                                              |
| **Permissions across teams**        | One team scope applies to all their permissions. You can't give someone Read on one team and Read / Write on another. |

{% hint style="warning" %}
**Get your team structure right before you scope anyone.** Team scope is only as accurate as your teams. An employee who isn't on any team — or is on the wrong one — won't appear for the manager who expects them.
{% endhint %}

### Transferring an employee to another manager's team

Each scoped manager can only see their own teams, so neither manager can move an employee between them on their own. There are two ways to handle a transfer:

* **Ask an administrator** — anyone with T\&A teams set to **All** can move the employee directly.
* **Use a shared Transfers team** — useful if transfers happen often.

**To set up a Transfers team (once):**

1. Someone who can manage teams creates a team called **Transfers**. Managing teams needs T\&A teams set to All, so this is usually an administrator or an Owner.
2. Add **Transfers** to the T\&A teams of every manager who might send or receive an employee.

**To make a transfer:**

1. The first manager moves the employee from their own team to **Transfers**.
2. The second manager moves the employee from **Transfers** to their own team.

{% hint style="warning" %}
Keep the stay on Transfers short. While an employee is on it, everyone with Transfers in their scope can see and work with them, and their former manager can no longer see them. Agree between the two managers when the move will be finished.
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://help.allwage.com/fundamentals/users-and-employees/user-permissions.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.