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:
Permissions
What an admin can do — approve a payment batch, send a funding decision, change settings
On the individual admin, under Users > Admins
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.
"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.
The permissions available
Applications
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
Can access Grants
Can access Assessments
Can access Assessment Rounds
Can access Assessments > Conflict of Interest
Can edit all Assessments
Contracts
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
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
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
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
Can edit Approval Limits
Off by default — see Admin Approval Limits
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.
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.
See also
Last updated
Was this helpful?