> For the complete documentation index, see [llms.txt](https://help.enterprise.ledger.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.enterprise.ledger.com/help-center-v2/administration/users/groups.md). # Groups How to use groups on Ledger Enterprise to manage several Operators at once in governance Rules. **Role: Master Administrators create and edit groups. Other Administrators can view them.** A group is a named set of Operators. Use a group in a Rule instead of naming individuals. ## Why groups matter Without groups, every Rule names people directly. When somebody joins or leaves, you have to edit every Rule that mentions them. Each edit is a separate approval cycle. With groups, you edit the group once. Every Rule that uses it follows. > **Note:** For a Workspace with more than a handful of Rules, this is the difference between a ten-minute change and a day of approvals. ## Create a group 1. Open **Groups** and select **Create group**. 2. Give it a name. 3. Optional: enter a **Description**. 4. Add Operators in **Members**. 5. Select **Review**. 6. Approve the Request on your Ledger device. Each new group is a **Request**. The Master Administrator quorum approves it. The group does not exist until those approvals complete. The name has up to 45 characters. No two groups of the Workspace can have the same name. The description is optional and holds up to 255 characters. The **Group details** panel shows the description under the group name. The **Members** field lists only active Operators who are not suspended. The API rejects any other user, so Administrators cannot be group members. The interface requires at least one member. There is no maximum. Name groups after the **role they play**, not the people in them. "Treasury Approvers" survives a change of staff. "Anna and Tom" does not. ## Edit a group Edit a group to add or remove Operators, or to change its name or description. This is also a governed Request, so it needs approval before it takes effect. Once approved, the change applies everywhere the group is used. While an edit Request on a group is pending, **Edit group** is unavailable for that group. Its tooltip reads "A request is already pending". The API also refuses a second edit of the group until the first Request ends. Groups cannot be deleted. > **Important:** An edit that leaves a group with fewer members than the quorum of a step that uses it is rejected. Lower that quorum in the Rules first. > > Plan the timing too. A group edit needs its own approval cycle, so it is not an instant fix when somebody leaves at short notice. ## Groups and quorum **An approval step holds either one group or a list of Operators.** It cannot hold several groups, or a group and named Operators together. In the Rule editor, an approval step cannot use a group or an Operator that another approval step of the Rule already uses. In the interface, the quorum of a step is at most its number of members minus 1, with a minimum of 1. The API accepts a quorum from 1 to the number of members. **A person counts once per Request.** When a person approves, the Request no longer asks them to approve in a later step. A person who is a member of two groups in the same Rule therefore approves in one step only. ## Related * [**Policies**](/help-center-v2/administration/governance/policies.md) * [**Creating and editing Accounts**](/help-center-v2/guides/accounts/creating-and-editing-accounts.md) * [**How governance works**](/help-center-v2/concepts/how-governance-works.md) --- # 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 by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://help.enterprise.ledger.com/help-center-v2/administration/users/groups.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.