> 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/group-management.md). # Group Management Groups are one of the important organisational tools available in CERTInext. While roles define what a user can do on the platform, groups define which resources a user can reach. Together, roles and groups form a two-layer access model that gives administrators precise control over both the actions a user may perform and the data they are permitted to see. ## What Is a Group A group in CERTInext is an organisational unit that clusters users together along with the resources those users own. Resources in this context include certificates, orders, domains, organisations, and discovered certificates. When a user is placed in a group, any certificate they request, any order they raise, and any domain they add becomes associated with that group. Other users who share that group - and whose role allows group-level access - can see and interact with those resources. Groups serve as the structural backbone of the access model. They allow a single CERTInext account to support multiple teams, departments, business units, or customer tenants operating independently from one another, while still being managed centrally by Administrators. A user can belong to one group or multiple groups simultaneously. Group membership is configured at the time of user creation and can be modified by an Administrator at any time. ## Why Groups Matter Without groups, access control in CERTInext operates entirely through role scopes - Own, Group, and All. For small accounts with a single team, this is sufficient. For larger accounts with multiple teams, business units, or customer sub-tenants, it creates a problem: any user with All scope can see every record across the entire account, regardless of which team owns it. Groups solve this problem by adding a second layer of control on top of roles. An Administrator can assign two Managers to different groups. Both managers hold the same role and the same view\_all scope, but because one is limited to Group A and the other to Group B, they each see only their own team's resources. Their capabilities are identical - only their reach differs. ## The Three Visibility Scopes Every resource-level permission in CERTInext is available at one or more of three visibility scopes: Own, Group, and All. Understanding these scopes is essential before working with groups, because group membership directly affects how each scope resolves in practice. ### Own The Own scope restricts a user to records they personally created or own. Group membership has no effect on Own-scoped access - a user with certificates.certificate.view\_own will only ever see certificates they personally requested, regardless of how many groups they belong to. Roles such as Basic User and Sub-Account User operate almost entirely at Own scope. ### Group The Group scope extends a user's access to all records belonging to any member of their assigned group. If a Manager holds certificates.certificate.view\_group and is assigned to Group A, they can see every certificate owned by every user in Group A. If that same Manager is also assigned to Group B, they can see certificates owned by users in both groups. Group membership directly determines the pool of records a Group-scoped permission can reach. ### All The All scope grants access to every record in the account, across every group. A user with certificates.certificate.view\_all can see every certificate regardless of who created it or which group that person belongs to - unless Account-Level Group Isolation is enabled, in which case All is reduced to the user's own group boundary. The three scopes are cumulative. If a role holds view\_own, view\_group, and view\_all for a given resource, CERTInext applies the most permissive and displays the broadest set of records the user is entitled to see. ## Scope Matrix for Key Roles The table below shows the effective visibility scope for key resource types across each default role. This matrix assumes Account-Level Group Isolation is disabled. When isolation is enabled, any All entry in the table becomes the user's group boundary, except for the Administrator who always retains full All scope.
ResourceAdministratorManagerDiscovery UserFinance MgrStandard UserBasic User
Certificates (view)AllAllNo accessAllAllOwn
Orders (view)AllAllAllAllAllOwn
Discovered Certs (view)AllAllAllNo accessAllNo access
Organisations (view)AllAllAllAllAllNo access
Domains (view)AllAllAllAllAllNo access
Certificates (revoke)AllAllNo accessNo accessOwnOwn
Users (view)AllAllAllNo accessAllNo access
## How Group Assignment Interacts With Role Scope The combination of a user's role scope and their group assignment determines their actual effective access. There are four common patterns that arise from this combination. ### All scope, no group restriction (default) When a role carries view\_all scope and the user has no group restriction applied, the user sees all resources in the entire account. This is how a standard Manager operates - full visibility across every record, regardless of which group owns it. ### All scope, limited to a specific group When a role carries view\_all scope and the user is limited to a specific group (for example, Group A only), the user sees all resources that belong to users in Group A but nothing from Group B, Group C, or any other group. The role's scope remains view\_all in name, but the group assignment acts as a ceiling on what that scope can resolve. ### Group scope, assigned to one or more groups When a role carries view\_group scope and the user belongs to a group, the user sees resources belonging to other members of that same group. If the user belongs to multiple groups, they see resources belonging to members of all their groups. If no specific group limitation is set, CERTInext uses the user's default group membership to determine the group boundary. ### Own scope, any group assignment When a role carries only view\_own scope, the user sees only their own records regardless of any group assignment. Group membership does not expand Own-scoped access.
## Groups and Credit Allocation CERTInext allows credits to be allocated at the group level, enabling account-wide credit budgets to be divided among teams. This is particularly useful for organisations that want each department or cost centre to operate within its own certificate budget. The settings.groups.allocate\_credits permission, held by the Administrator, Finance Manager, and Manager roles, enables this. To allocate credits to a group, navigate to Settings > Groups, open the Group Detail page for the relevant group, and locate the Credits section. Enter the number of credits to allocate and confirm. Users in that group will draw from the group's allocated credit balance when placing certificate orders. Credits can be reallocated or withdrawn at any time.
## Exporting the Groups List The Administrator can export the full groups list to a file using the settings.groups.export permission. From the Groups tab, click the Export button to download the list in the available format. This is useful for audits, capacity reviews, or configuration documentation.
## Practical Scenarios ### Scenario 1: Single Team, No Group Restrictions In a small organisation where all users work within a single team, groups are not strictly necessary. All users can be left in the default group with no group restrictions applied. The access model functions entirely through role scopes, and any Manager or Standard User with All scope will see the full account's resources without any group ceiling. Account-Level Group Isolation should remain disabled. ### Scenario 2: Multi-Team Organisation with Separate Certificate Estates A financial services organisation has three teams: Infrastructure, Application Security, and Compliance. Each team manages its own certificate estate and must not see other teams' certificates. The Administrator creates three groups - Infrastructure, AppSec, and Compliance - and assigns all users to their respective group with the "Limit this user to access specific groups" checkbox enabled. Managers in each group can manage all resources within their own team. Account-Level Group Isolation can optionally be enabled to enforce this separation at the platform level. 📷 Screenshot: Groups list - multi-team setup *Show the Groups list with three configured groups (for example, Infrastructure, AppSec, and Compliance) with member counts and credit balances, illustrating a typical multi-team setup.* ### Scenario 3: Reseller Account with Multiple End-Customers A reseller operates a single CERTInext account on behalf of five end-customers. Each customer must be entirely isolated from the others - they should not see each other's certificates, orders, or domains. The Administrator creates one group per customer, assigns each customer's users to their group, and enables Account-Level Group Isolation. Each customer's operational lead is given a Manager role and sees only their own group's data. All end-customers operate independently within the same platform account. ### Scenario 4: Cross-Team Audit Access The Security Operations team (Group: SecOps) needs to review certificates owned by the Infrastructure team (Group: Infra) for compliance auditing, but should not have access to the Finance team's records. The Administrator navigates to the SecOps group detail page, opens the Cross-Group Access section, and adds a cross-group rule granting SecOps members Group-scope access to Infra's resources. SecOps members can now see Infra's certificates and orders, and the Finance group's data remains inaccessible to them. ## Best Practices for Group Management Groups are most effective when their boundaries reflect real organisational divisions. Naming groups after teams, departments, or business units - rather than technical constructs - makes the configuration intuitive for future Administrators who may not have been involved in the initial setup. Every user should be assigned to at least one group. Users without an explicit group assignment may behave unpredictably when group-scoped permissions are evaluated, particularly when Account-Level Group Isolation is enabled. Always set group membership explicitly at user creation. Avoid assigning users to an excessive number of groups unless the use case genuinely requires broad cross-team access. Multi-group membership widens a user's visible dataset progressively, which can undermine the separation-of-duties intent of the group model. When broader access is needed temporarily, use cross-group access rules at the group level so the permission is auditable and can be revoked cleanly. Review cross-group access rules regularly. As teams restructure and projects conclude, access rules created for a specific purpose may persist beyond their intended lifetime. A periodic audit of the Groups tab and its cross-group configuration ensures that the access model stays aligned with the organisation's current structure. When enabling Account-Level Group Isolation, communicate the change to affected users in advance. Users who previously had account-wide visibility will notice an immediate reduction in the records they can see, and without warning this can cause confusion or unnecessary support requests. ## Groups, Scopes, and Isolation Together The three mechanisms - group membership, visibility scopes, and account-level isolation - work as complementary layers. Role scopes define what a user can do and at which breadth. Group membership defines the organisational boundary within which that breadth operates. Cross-group access rules create controlled exceptions to those boundaries. Account-Level Group Isolation enforces those boundaries at the platform level, overriding individual role scopes for all non-Administrator users simultaneously. Used together, these tools allow a single CERTInext account to serve organisations of any size and structure - from a single team sharing full visibility, to a complex multi-tenant environment with strict, auditable data separation between every 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/group-management.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.