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 and teams.
Related pages:
Quick Start: Who Gets Which Preset — the short version: common jobs and exactly what to choose
Users — adding, editing and deleting users
Permission Presets — the built-in presets, and building your own
Designing and Troubleshooting Access — choosing a preset, Owners, and fixing access problems
Payroll Permissions — payroll scope, payroll permissions and reports
The Three Layers
When someone signs in, AllWage answers two questions about everything they try to do:
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?
Which records can they do it to? Which employees, and which of their records?
The answers are held in three layers:
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.
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 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.
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.
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.
Team Scope in Practice
These rules apply to a user whose T&A teams are set to specific teams.
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.
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.
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):
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.
Add Transfers to the T&A teams of every manager who might send or receive an employee.
To make a transfer:
The first manager moves the employee from their own team to Transfers.
The second manager moves the employee from Transfers to their own team.
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.
Last updated
Was this helpful?