> ## Documentation Index
> Fetch the complete documentation index at: https://sofiedocs.usetransfer.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Groups

> Use Sofie groups to organize users for teams, departments, projects, and review cohorts.

Groups organize users. They help administrators manage people as teams instead of as individual accounts.

Use groups for user organization. Use roles for permissions. Use Workspace membership for project-specific content access.

## Good group uses

Groups work well for:

* Departments.
* Site teams.
* Project teams.
* Review boards.
* External collaborator sets when allowed.
* Training cohorts.
* Workspace member administration.

Good group names:

* `QA reviewers`.
* `MSAT tech transfer`.
* `Validation authors`.
* `Manufacturing SMEs`.
* `Regulatory reviewers`.

## Create a group

<Steps>
  <Step title="Open Group Management">
    Go to **Users** and choose **Manage Groups**.
  </Step>

  <Step title="Create a group">
    Click **New Group**.
  </Step>

  <Step title="Name the group">
    Use a team or responsibility name that other administrators will recognize.
  </Step>

  <Step title="Add users">
    Add the users who belong together.
  </Step>

  <Step title="Review related access">
    Check whether the group needs Workspace membership or role changes.
  </Step>
</Steps>

## Group maintenance

Review groups when:

* A project closes.
* A department changes.
* New users join.
* A user changes teams.
* A reviewer group changes responsibility.
* A Workspace should no longer be shared with that group.

## Groups, roles, and Workspaces

| Question                                               | Check                                            |
| ------------------------------------------------------ | ------------------------------------------------ |
| Who belongs to this team?                              | Group.                                           |
| What can this person do in Sofie?                      | Role.                                            |
| Can this person see this project content?              | Workspace membership or sharing.                 |
| Should several people receive the same project access? | Group plus Workspace membership where supported. |

<Tip>
  Keep group names stable. If the group name changes every time a project phase changes, users and admins will have trouble understanding access later.
</Tip>

## Avoid group sprawl

Too many groups make access harder to review.

Avoid creating a new group when:

* A Workspace membership change is enough.
* Only one person needs access.
* The group will be used for less than a short project phase.
* A role change would be more accurate.

## Offboarding and group cleanup

When a user leaves a team:

* Remove the user from groups they no longer need.
* Check Workspace memberships tied to those groups.
* Confirm they no longer receive unrelated notifications.
* Review role assignment if the group reflected an elevated responsibility.

## Group branding

Group branding lets administrators set the document logo and colors for members of a group. Use it when a department, site, client team, or project group should use different generated document branding than the organization default.

Group brand fields include:

* Logo.
* Primary color.
* Secondary color.

Blank group brand fields inherit from organization branding. If personal branding is enabled, a user's personal brand fields take precedence over group branding.

<Steps>
  <Step title="Open the group">
    Go to **Users**, choose **Manage Groups**, and open the group.
  </Step>

  <Step title="Find Group Brand">
    Use the **Group Brand** section.
  </Step>

  <Step title="Update logo and colors">
    Upload or remove the logo, then set **Primary** and **Secondary** colors.
  </Step>

  <Step title="Save">
    Click **Save**.
  </Step>
</Steps>

See [Document branding](/admin/document-branding) for the full organization, group, and personal branding hierarchy.