> 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/admin-groups-and-data-access-rules.md). # Admin Groups & Data Access Rules Admin Groups and Data Access Rules give you granular control over what data each administrator can see and edit. Instead of every admin having identical access to all records, you can tailor permissions to match your team structure, operational boundaries, and security requirements. Access to this feature is tightly governed. The ability to create, view, and modify Admin Groups is controlled by a dedicated permission - **"Can manage Admin Groups"** - which is off by default. Until this permission is explicitly granted, the Admin Groups interface is not visible. This means your organisation decides who can configure access, and everyone else simply operates within the access they've been given. ### Admin Groups An Admin Group is a collection of administrators who share the same level of access. You'll find them under **Users > Admin Groups**.

The Admin Groups list under Users > Admin Groups

Each group has: * **Members** - the admin users who belong to the group * **One or more Data Access Rules** - the rules that define what those members can see and do An admin can belong to multiple groups. When they do, the system combines all their rules and grants the **highest level of access** found for each record type (more details below). This means adding someone to a group can only maintain or increase their access, it never reduces it. ### Data Access Rules A Data Access Rule is attached to an Admin Group and defines two things: **what level of access** the group has to each record type, and **which records** that access applies to. For each record type, a rule specifies one of three levels: | Access Level | What It Means | | --------------- | ------------------------------------ | | **Full Access** | View and edit records | | **Read Only** | View records but cannot make changes | | **No Access** | Records are hidden entirely |

Setting access levels for each record type using the dropdowns

### Record types The following record types can be controlled: | Record Type | What It Covers | | ----------------- | ---------------------------------------------------- | | Applicants | Applicant and provider profiles | | Funding Rounds | Funding programmes and their settings | | Applications | Funding applications submitted by applicants | | Assessments | Assessment reviews of applications | | Conditions | Conditions placed on approved applications | | Milestones | Contract and application milestones and deliverables | | Contracts | Funding contracts | | Payments | Payment records and batches | | Internal Comments | Admin-only comments on records | ### Criteria (scope) Each rule also defines **which records** the access levels apply to: * **Any Criteria** - the access levels apply to all records across the entire organisation. Use this for senior administrators, system administrators, or finance teams who need visibility of everything. * **Specific Funding Rounds** - the access levels apply only to records linked to selected funding rounds or funding categories. Use this for programme managers, regional teams, or anyone who should only see specific programmes. When using specific criteria, you can select: * **Individual funding rounds** - e.g. "2025 Community Fund Round 1" * **Funding categories** - e.g. "Youth Programmes" (automatically includes all rounds in that category, including any future rounds added to it) * **A combination of both**

Choosing Specific Funding Rounds criteria with funding categories and individual rounds

### The Default Group Every organisation has a **Default Group**. This group: * Automatically includes all current administrators * Automatically adds any new administrators when they are created * Cannot have members manually removed The Default Group establishes a baseline level of access that every admin receives. Out of the box, it comes with an unrestricted Data Access Rule (Full Access to all record types with Any Criteria), so all admins start with the same access they had before this feature was introduced. You can adjust the Default Group's Data Access Rule to set a different baseline - for example, Read Only across the board - and then use additional groups to grant higher access where needed. ### Governance & the "Can manage Admin Groups" Permission The entire Admin Groups feature is gated behind a single permission: **"Can manage Admin Groups"**. This permission is **disabled by default** for all roles, and it controls everything - creating groups, viewing group membership, editing Data Access Rules, and deleting groups. This design is deliberate. The administrators who decide *who can see what* should be a small, trusted group - typically system administrators or team leads responsible for access governance. Granting this permission broadly would undermine the purpose of having controlled access in the first place.

The "Can manage Admin Groups" permission on the administrator permissions form

### How Permissions Stack When an admin belongs to multiple groups, the system evaluates all their Data Access Rules and grants the **highest access level** found for each record type. **Example:** An admin belongs to two groups: * Group A grants **Read Only** to Applications * Group B grants **Full Access** to Applications The admin receives **Full Access** to Applications (the higher of the two). The priority order is: **Full Access > Read Only > No Access**. Because the model is additive, the only way to reduce an admin's access is to remove them from a group or change that group's Data Access Rule. ### Setting this up Ready to configure this for your organisation? See [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) for the setup steps, and [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) for common starting points. ### Things to Know * **Changes take effect immediately.** When you update a group's membership or Data Access Rules, the changes apply on the admin's next page load. No restart or waiting period is required. * **Funding categories are forward-looking.** When you scope a rule to a funding category, any new funding round added to that category in the future is automatically covered. You don't need to update the rule each time a new round is created. * **No disruption for existing users.** The Default Group with unrestricted access means all existing admins continue to see and do everything they could before. Access only changes when you deliberately configure it. * **Audit-friendly.** The group structure gives you a clear, reviewable record of who has access to what, supporting compliance and governance requirements.