> For the complete documentation index, see [llms.txt](https://docs.certinext.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.certinext.io/documentation/user-roles-and-access-control/role-based-access-control/group-level-access-controls.md).
# Group Level Access Controls
Group-Level Access Controls are a new capability introduced as part of the RBAC enhancement release. They provide greater flexibility in designing access policies while enabling stronger governance and separation of duties across teams.
#### What Are Groups
Groups in CERTInext are organisational units that cluster users and the resources they own - certificates, orders, domains, and organisations. A user can belong to one or more groups. Groups form the foundation for the group-level access model, which allows two users with the same role to have completely different visibility depending on their group assignments.
For example, two Managers may both hold the `certificates.certificate.view_all` permission, but if one Manager is limited to Group A and the other is not limited to any specific group, the first Manager will only see certificates belonging to users in Group A, while the second Manager will see every certificate across the account.
#### The Three Visibility Scopes in Practice
The Own scope restricts a user to records they personally created or own. A Basic User with `certificates.certificate.view_own` can only see certificates they personally requested, regardless of how many groups they belong to.
The Group scope extends a user's reach to records belonging to any member of their assigned group. A Manager assigned to Group A with `certificates.certificate.view_group` can see certificates owned by any user in Group A, but not certificates in Group B.
The All scope grants access to every resource in the account, across all groups. A Manager with `certificates.certificate.view_all` can see every certificate regardless of which user created it or which group that user belongs to. The three scopes are cumulative - if a role has `view_own`, `view_group`, and `view_all`, CERTInext applies the most permissive and displays the broadest set of records the user is entitled to see.
#### How Group Assignment Interacts With Scope
When you create a user, you can choose to limit them to specific groups using the "Limit this user to access specific groups" checkbox on the Add User form. This group assignment acts as a ceiling on their effective scope.
A Manager with `view_all` who is not limited to specific groups will see all resources in the entire account. A Manager with `view_all` who is limited to Group A only will see all resources belonging to users in Group A. A Standard User with `view_group` who is not limited to a specific group will see resources belonging to their default group. A Basic User with `view_own` will see only their own resources regardless of any group assignment.
#### Cross-Group Access Configuration
CERTInext allows Administrators to configure which specific groups may access resources belonging to other groups, enabling controlled cross-functional collaboration without opening up full account-wide access. For example, a Security Operations team in Group B might need to view certificates owned by the Infrastructure team in Group A for auditing purposes, without being able to see the Sales team's certificates in Group C.
To configure cross-group access, log in as an Administrator and navigate to Settings > Groups. Click View next to the group whose members you want to grant cross-group access. On the Group Detail page, locate the Cross-Group Access section.
Click Add or Configure to open the cross-group access controls. Select the groups whose resources members of this group should be able to reach, and specify the permitted scope for each cross-group link (Own, Group, or All for that target group's resources). Click Save. The cross-group rules take effect immediately.
Cross-group access overrides the "Limit this user to specific groups" setting for the configured groups. Review cross-group rules carefully - granting Group A access to All resources in Group B can expose a large volume of data. Always apply the minimum necessary scope.
### Account-Level Group Isolation
Account-Level Group Isolation is a new capability introduced in the RBAC enhancement release. It provides the strongest form of data segmentation available in CERTInext.
#### What Is Account-Level Group Isolation
Account-Level Group Isolation is a single account-wide switch that, when enabled, forces every non-Administrator user to see and interact with only the resources that belong to their designated group - regardless of what their role's scope would ordinarily allow. A Manager who could normally see all certificates across the entire account will, once isolation is enabled, only see certificates in their own group.
The Administrator role is explicitly excluded from this restriction. An Administrator always retains full visibility and management capabilities across all groups and all entities in the account, even when isolation is enabled.
#### When to Use Group Isolation
Group isolation is most valuable in multi-team or multi-department accounts where each team manages its own certificates and should not see or accidentally interfere with another team's work. It is equally important in reseller or partner accounts where multiple end-customers, each in their own group, operate within a single CERTInext account and must be kept strictly separate. Organisations with regulatory or compliance requirements for data segmentation between organisational units will also find this setting essential. Beyond governance, restricting users to their group minimises the impact of mistakes - a user simply cannot revoke a certificate they should not be touching.
Group isolation is an account-wide setting that applies to all non-Administrator users simultaneously. If you need more targeted, user-by-user group restrictions, use the "Limit this user to specific groups" checkbox on the Add/Edit User form instead. Both approaches can be used together.
#### Effect on Role Scopes
When Account-Level Group Isolation is enabled, the effective scope of every non-Administrator role changes. Permissions that previously granted "All" scope are reduced to the user's group boundary. The Administrator remains unaffected and retains All scope for every permission. For Standard Users, their `view_all` access for certificates, orders, domains, and organisations becomes effectively group-scoped. For Discovery Users, their access to discovered certificates and bots is limited to their own group. For Managers, their account-wide operational visibility narrows to their designated group.
---
# 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 dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.certinext.io/documentation/user-roles-and-access-control/role-based-access-control/group-level-access-controls.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
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.