> For the complete documentation index, see [llms.txt](https://help.tahua.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.tahua.io/knowledge-base/administrator-help-guides/administrator-permissions-and-user-management/administrator-permissions.md). # Administrator Permissions Administrator permissions control what actions an admin can perform — approving payments, sending decisions, changing settings. They work alongside Admin Groups, which control which records an admin c Access in Tahua is controlled by two separate layers, and it's worth understanding both: | Layer | Controls | Where you set it | | ------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------- | ------------------------------------------------- | | **Permissions** | What an admin can **do** — approve a payment batch, send a funding decision, change settings | On the individual admin, under **Users > Admins** | | [**Data Access Rules**](/knowledge-base/administrator-help-guides/administrator-permissions-and-user-management/admin-groups-and-data-access-rules.md) | Which **records** an admin can see, and whether they can edit them | On an Admin Group, under **Users > Admin Groups** | An admin needs both. A permission to approve payment batches is only useful if their Data Access Rules also let them see Payments — and conversely, being able to see Payments doesn't let someone approve a batch unless they hold the permission. ## Setting permissions Open **Users > Admins**, find the administrator and open their record. Permissions are grouped by area, and you tick the ones that admin should hold. Permissions are set **per administrator**, not per role, so two people with the same job title can hold different permissions. It's worth reviewing them periodically rather than assuming they match. {% hint style="warning" %} **"Can edit Permissions"** allows an administrator to change permissions — including their own. Anyone holding it can grant themselves any other permission, so it should be limited to the people responsible for access governance. {% endhint %} ## The permissions available ### Applications | Permission | Notes | | ------------------------------------------------------ | -------------- | | Can access Applications > Funding Applications | | | Can access Applications > Funding Decisions | | | Can delete an application | | | Can directly set the approved amount on an Application | Off by default | | Can send Funding Decisions | Off by default | ### Grants and Assessments | Permission | Notes | | --------------------------------------------- | ----- | | Can access Grants | | | Can access Assessments | | | Can access Assessment Rounds | | | Can access Assessments > Conflict of Interest | | | Can edit all Assessments | | ### Contracts | Permission | Notes | | --------------------------------------------------- | -------------- | | Can access Contracts > Manage Contracts | | | Can access Settings > Contract Categories | | | Can change reviewer on letters and contracts | | | Can replace digital contract with external contract | | | Can change amount on a Contract after signing | Off by default | | Can change the dates on a signed contract | Off by default | ### Milestones and Payments | Permission | Notes | | ------------------------------- | --------------------------------------------- | | Can access Manage Milestones | | | Can Approve a Milestone | | | Can Decline a Milestone | | | Can access Payments | | | **Can approve Payment Batches** | Controls who can approve payments for release | ### Reviews and Reports | Permission | Notes | | -------------------------------------- | ----- | | Can approve Review Requests | | | Can mark fields to require Review | | | Can generate reports | | | Can create and update reports | | | Can generate document reports | | | Can create and update document reports | | ### Users and Settings | Permission | Notes | | ----------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Can access Users | | | Can access Users > Admins | | | **Can edit Permissions** | Can change permissions, including their own | | Can manage Admin Groups | Off by default — see [Admin Groups & Data Access Rules](/knowledge-base/administrator-help-guides/administrator-permissions-and-user-management/admin-groups-and-data-access-rules.md) | | Can edit Approval Limits | Off by default — see [Admin Approval Limits](/knowledge-base/administrator-help-guides/administrator-permissions-and-user-management/admin-approval-limits.md) | | Can access Settings > Organisation | | | Can access Settings > Templates | | | Can access Settings > Emails | | | Can access Settings > Email Logs | | | Can access Settings > Funding Categories | | | Can access Settings > Payment Categories | | | Can manage Integrations under Settings > Organisation | | | Can view and edit tasks assigned to other users | | ## Separating duties A common requirement is preventing one person from both approving a payment and changing the bank account it pays to. This is achievable, but it needs both layers configured together — permissions alone won't do it. **Approving payments** is a permission: *Can approve Payment Batches*. **Bank account details** are not held on the Payment record. They sit on the **Contract** and on the **Applicant** profile, so they're governed by the **Contracts** and **Applicants** access levels in that admin's Data Access Rules. To let someone approve payments but not change bank details: * Grant **Can approve Payment Batches** and **Can access Payments** * In their Data Access Rules, set **Payments** to Full Access * Set **Contracts** and **Applicants** to **Read Only** They can then approve payments and view the account being paid, but cannot alter it. {% hint style="warning" %} **Data access is additive.** Where an admin belongs to more than one group, they receive the **highest** access level found across all their groups. You cannot restrict someone by adding a more limited group — you have to make sure no group grants the access you're trying to withhold, including the Default Group. If your Default Group still has its original unrestricted rule, every admin has Full Access to everything regardless of any other group. Restricting the Default Group's rule is usually the first step. {% endhint %} {% hint style="info" %} Where several people share a single login, duties cannot be separated in practice — the shared account holds every permission granted to it, and audit records identify the account rather than the person. Named individual accounts are needed for separation of duties to hold up. {% endhint %} ## See also * [Admin Groups & Data Access Rules](/knowledge-base/administrator-help-guides/administrator-permissions-and-user-management/admin-groups-and-data-access-rules.md) * [How to Create an Admin Group and Set Data Access Rules](/knowledge-base/administrator-help-guides/administrator-permissions-and-user-management/admin-groups-and-data-access-rules/how-to-create-an-admin-group-and-set-data-access-rules.md) * [Example Admin Group Configurations](/knowledge-base/administrator-help-guides/administrator-permissions-and-user-management/admin-groups-and-data-access-rules/example-admin-group-configurations.md) * [Admin Approval Limits](/knowledge-base/administrator-help-guides/administrator-permissions-and-user-management/admin-approval-limits.md)