> For the complete documentation index, see [llms.txt](https://docs.openiam.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.openiam.com/end-user-guide-for-selfservice/for-managers/group-management.md).

# Group management

Request a new group, clone an existing one, and manage who approves membership.

Groups are how access is granted to many people at once. This page covers creating them and deciding who approves joining them.

Open the options from **Access Management → Create Group Request**, **Clone Group**, and **Group Management**.

## Requesting a new group

Use **Create Group Request** when a set of people needs shared access that no existing group provides.

{% stepper %}
{% step %}
**Give the group a name and description.**

Use a name that will still make sense to someone else in two years. *Finance — Quarterly Reporting* is useful; *Group 4* is not. The description should say who the group is for and what it grants.
{% endstep %}

{% step %}
**Choose the group type and managed system**, if the group lives in a system such as a directory.
{% endstep %}

{% step %}
**Set who approves membership.**
{% endstep %}

{% step %}
**Select the access the group will carry.**

The roles, resources, and entitlements every member will receive.
{% endstep %}

{% step %}
**Submit for approval.**

New groups normally need approving, since creating one creates a new way to grant access.
{% endstep %}
{% endstepper %}

## Cloning a group

**Clone Group from Existing** copies a group's access into a new group. It's the fastest way to create something similar to what already works — a second regional team, a parallel project.

{% stepper %}
{% step %}
**Select the group to copy.**

If you don't, you're told *"Please select a group"*.
{% endstep %}

{% step %}
**Give the new group a name.**

Required — *"Please provide a new group name"* if you skip it.
{% endstep %}

{% step %}
**Choose which entitlements to carry over.**

**Select Entitlements** lets you take everything, or only part. Cloning is a good moment to leave behind access the original accumulated but never really needed.
{% endstep %}

{% step %}
**Check the preview.**

The **Preview** table shows exactly what the new group will carry — roles and other entitlements. Read it before submitting; this is where you catch a clone that brings across more than you intended.
{% endstep %}

{% step %}
**Submit.**
{% endstep %}
{% endstepper %}

{% hint style="warning" %}
Cloning copies whatever the original holds, including anything it shouldn't. If the source group has grown over the years, review the preview rather than trusting it — otherwise you've just doubled the problem.
{% endhint %}

## Group approvers

**Group approver associations** decide who approves requests to join a group. Getting this right is what makes group requests work: the approver should be someone who knows whether a person genuinely needs that access.

Points worth attention:

* **Name a role or several people, not one individual.** A single named approver becomes a bottleneck the moment they take leave.
* **Choose someone close to the work.** An approver who doesn't understand what the group grants will either rubber-stamp or stall.
* **Review it when people move on.** Groups whose approver has left are a common cause of requests that never get decided — see [Request administration](/end-user-guide-for-selfservice/approvals/request-administration.md).

## Keeping groups useful

* **One group, one purpose.** Groups that accumulate unrelated access become impossible to review.
* **Don't create a group for one person.** That's an individual grant; making it a group hides it.
* **Retire groups nobody uses.** An empty group with live access is an accident waiting to be granted.


---

# 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://docs.openiam.com/end-user-guide-for-selfservice/for-managers/group-management.md?ask=<question>&goal=<user_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.