> 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/designing-and-troubleshooting-access.md). # 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](/fundamentals/users-and-employees/user-permissions.md) and [Permission Presets](/fundamentals/users-and-employees/user-permissions/permission-presets.md) first. ## Who Can Manage Users and Presets These permissions are in the **Administration** area of a preset. | Permission | What Read / Write allows | Built-in presets | | ----------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------- | | **Users** | Inviting users, linking them to presets, choosing their scope, resending invitations, resetting and unlocking accounts, and archiving and restoring 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. {% hint style="warning" %} 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. {% endhint %} ### 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 archived. * **You can't remove your own Owner access.** Another Owner has to do it. * **Only an Owner can reset, unlock or archive another Owner's account.** {% hint style="info" %} Aim for at least two Owners, so you're never stuck if one leaves or can't sign in. Keep the list short — Owner means "this person controls who can get into the system". {% endhint %} **To make someone an Owner:** 1. On the [Users](/fundamentals/users-and-employees/users.md) page, click **⋯** on the user's row and choose **Edit access**. 2. Open the preset picker and choose **Owner**. 3. 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 — inviting new starters, resending invitations, unlocking or resetting accounts, archiving 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](#example-4-trainees-who-only-see-certain-teams). * 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](/fundamentals/users-and-employees/user-permissions/payroll-permissions.md). **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: 1. **The preset** — is the user linked to the preset you expect? 2. **The permission** — does that preset give Read or Read / Write on the area? 3. **The scope** — is the record inside the user's scope? Most problems are scope. | Complaint | What to check | | ------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | "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](/fundamentals/users-and-employees/user-permissions/payroll-permissions.md#troubleshooting-payroll-access). | ### 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. 1. Start Debug permissions for the user and confirm the problem the way they see it. 2. Stop debugging, then fix the problem on the user's preset or scope as yourself. 3. Debug again to check the fix. {% hint style="warning" %} You're looking at real employee information. Only use Debug permissions when you have a reason to. {% 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/designing-and-troubleshooting-access.md?ask=&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.