Designing and Troubleshooting Access
Who can manage users and presets, how to choose the right preset for each job, and how to work out why someone can see too much or too little.
This page brings presets, permissions and scope together. It covers who controls access, a simple way to choose the right preset for every job in your organisation, and how to diagnose access problems when something doesn't look right.
What this page covers:
Who can manage users and presets, and what makes someone an Owner
Choosing a preset: four questions
Worked examples
Checking access with the Resolved access preview
Diagnosing access problems, including Explore employee access and Debug permissions
Who this is for:
Owners and administrators who design and look after access. Read User Permissions and Permission Presets first.
Who Can Manage Users and Presets
These permissions are in the Administration area of a preset.
Users
Adding users, linking them to presets, choosing their scope, sending password resets and deleting users.
Owner: Read / Write. Everyone else: Read.
Permission presets
Creating, copying, editing and deleting presets.
Owner: Read / Write. Everyone else: Read.
External API tokens
Connecting other systems to AllWage.
Owners only — no preset can give this.
Audit log
Reading every recorded change on the site (Read only).
Owner. Can be added to a custom preset.
Users and Permission presets are always at least Read. Everyone can see the list of users and the preset each user is linked to, but only Read / Write lets someone change them.
The audit log isn't limited by scope. It shows changes to records outside a user's teams too, so AllWage warns you if you add it to a scoped preset.
Owners
An Owner is someone linked to the Owner preset. Owners have full access to everything, manage users and presets, read the audit log and manage external API tokens.
Only an Owner can make someone an Owner, or change another Owner's access.
There must always be at least one Owner. The last Owner can't be moved to another preset or deleted.
You can't remove your own Owner access. Another Owner has to do it.
To make someone an Owner:
On the Users page, click ⋯ on the user's row and choose Edit access.
Open the preset picker and choose Owner.
Click Save, then Make Owner to confirm.
Making someone an Owner replaces their current access and scope with full access.
To remove Owner: link the user to a different preset the same way, then confirm with Remove Owner.
A help-desk preset
To let someone look after accounts day to day — adding new starters, sending password resets, removing leavers — without making them an Owner, build a custom preset from the preset that fits their everyday job and raise Users to Read / Write, leaving Permission presets at Read. They can link users to existing presets, but can't build or change presets, and can't make anyone an Owner.
A custom preset with Read / Write on both Users and Permission presets is nearly as powerful as Owner, and AllWage warns you when you build one. It still can't make anyone an Owner or manage API tokens, and doesn't count towards "at least one Owner".
Choosing a Preset: Four Questions
List the jobs in your organisation, not the people, and give each job one preset. For each job, work through these questions in order and stop at the first that gives you an answer.
1. Should they control who can access AllWage — adding users and building presets? Yes → Owner.
2. Should they change setup shared by the whole organisation — clock templates, activities, devices, custom metrics, teams? Yes → Admin — T&A only, or Admin — Full if they also run payroll.
3. Should they change day-to-day records — clocks, leave, hours, biometrics?
No → User — T&A only (unscoped), or the Full version if they should also read payroll. If they should only read some teams, see Example 4.
Yes → User — T&A only (scoped), and choose the teams whose data they can change. If they also work on payroll, choose User — Full (scoped) — see Payroll Permissions.
4. Is the preset almost right, but one thing needs to differ? Build a custom preset, and build it upward: start from the built-in with the least access that fits and raise specific permissions. Name it after the job.
Worked Examples
Example 1: the team manager
The job: look after one team's day-to-day time and attendance. No shared setup, no payroll, no documents.
Preset: User — T&A only (scoped), with T&A teams set to their own team. Every team manager uses the same preset — only their teams differ.
Example 2: the head-office administrator
The job: run time and attendance for the whole organisation, including clock templates, activities, devices and sites. No payroll.
Preset: Admin — T&A only. They can read the list of users and presets, but managing them stays with the Owners.
Example 3: trainees who see everything
The job: new coordinators who need to see all time and attendance, but change nothing.
Preset: a custom preset based on User — T&A only (unscoped), called T&A Trainee. If trainees later need to read employees' documents, raise Employee documents from No access to Read on the preset once, and every trainee gets it. When a trainee is promoted to run a team, move them to User — T&A only (scoped) instead of changing the trainee preset.
Example 4: trainees who only see certain teams
The job: trainees placed with specific teams, who must not change anything and should only see those teams' employees.
Preset: copy User — T&A only (unscoped) to make a custom preset, and give it a team scope — specific teams if all the trainees are placed with the same teams, or Set per user if each is placed differently. The unscoped User preset is read-only on all operational data, so the copy is too. The scope only narrows which employees they see.
When a job doesn't fit neatly
A user has one team scope, and it applies to all their permissions. If a manager should change their own team's data but only read a second team, you have to choose: include the second team with the same access, or leave it out.
Checking Access with the Resolved Access Preview
When you add a user, edit a user or edit a preset, the Resolved access panel shows what the user will — and won't — be able to do, worked out from their preset and scope together:
What this user can see — employees and teams, including how many employees they can't see.
What this user can do — every area, grouped by what they can change, what they can only read, the reports they can run, and what they have no access to.
Why some access is limited — anything the preset allows but the user's scope doesn't support, with the reason.
Check the no access group as carefully as the rest. The point of the preview is to confirm what someone can't reach.
A checklist for your organisation
Get the team structure right first — every employee on the right team.
List the jobs, and give each job one preset.
Use the four questions to choose a built-in; build custom presets only for what's different, and build them upward.
Name and describe every custom preset.
Decide per preset whether scope is fixed or Set per user.
Keep shared setup at Read for scoped users, unless you mean otherwise.
Keep Owners to two or three people.
Check every user with the Resolved access preview.
Diagnosing Access Problems
Every access problem comes from one of three places. Check them in this order:
The preset — is the user linked to the preset you expect?
The permission — does that preset give Read or Read / Write on the area?
The scope — is the record inside the user's scope?
Most problems are scope.
"I can't see one of my employees."
Is the employee on a team, and on the right team? Is that team in the user's T&A teams?
"I can see the employee but can't change their clocks."
Does the preset give Read / Write on clocks? Is the employee on one of the user's teams? An employee can be visible through payroll without being on the user's teams.
"I can't change a clock template."
Usually intended — scoped users only read shared setup. If they genuinely should, that's a decision about their job and a different preset.
"They can see too much."
Are they on an unscoped preset that should be scoped? Have they been given more teams than they need? Do they have payroll access? See Payroll Permissions.
Explore employee access
In a user's Edit access panel, Explore employee access lists every employee on the site and whether this user can see them, with the reason for each — for example "Team Packing is outside their team access" or "Not in their T&A teams, so they can't make changes". Search for the employee in question and read the reason.
It's available to users with Read / Write on Users, T&A teams set to All and Read on employee records — Owners, for example.
Debug permissions
Debug permissions lets an Owner see AllWage exactly as another user sees it — their menus, their employees and their screens. It's view-only: a banner shows whose permissions you're using, and changes are disabled.
Start Debug permissions for the user and confirm the problem the way they see it.
Stop debugging, then fix the problem on the user's preset or scope as yourself.
Debug again to check the fix.
You're looking at real employee information. Only use Debug permissions when you have a reason to.
Last updated
Was this helpful?