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

# Humans

> Manage your reviewers with the Humans system -- Universe, Groups, and People

# Humans

The Humans system is how you manage the people who review items in your HITL.sh workflows. It provides a structured way to organize reviewers into groups and assign them to human review nodes.

## Core Concepts

The Humans system has three layers:

> [card] Universe
>
> Your default group. Every person you add to HITL.sh is automatically part of your Universe.

> [card] Groups
>
> Named collections of people. Groups can be nested inside other groups, and a person can belong to multiple groups.

> [card] People
>
> Individual reviewers. Each person has an email address, name, and optional metadata.

## Universe

The Universe is the top-level group that contains all of your people. You do not need to create it -- it exists automatically for every account.

When you assign a human review node to "Universe," every person in your account is eligible to receive and respond to that review request. This is useful for small teams or when any reviewer can handle any request.

## People

People are the individual humans who review items in your workflows. You add people by inviting them via email.

### Adding People

**1. Navigate to Humans**

Open the **Humans** section in your dashboard sidebar.

**2. Invite by email**

Click **Add Person** and enter their email address. They will receive an invitation to join HITL.sh.

**3. They accept the invite**

The person creates an account (or logs in if they already have one), downloads the mobile app, and is ready to receive review requests.

### Person Properties

Each person has:

* **Email**: Their unique identifier and login
* **Name**: Display name shown in the dashboard and mobile app
* **Groups**: Which groups they belong to (they are always in the Universe)
* **Status**: Active, pending (invited but not yet accepted), or deactivated

## Groups

Groups let you organize people by team, function, skill, or any other dimension. When you assign a human review node to a group, only members of that group receive the review request.

### Creating Groups

**1. Navigate to Humans**

Open the **Humans** section in your dashboard.

**2. Create a group**

Click **New Group**, give it a name and optional description.

**3. Add members**

Add people to the group. You can also add existing groups as sub-groups.

### Nesting Groups

Groups can contain other groups. For example:

```
Engineering
  +-- Frontend Team
  +-- Backend Team
  +-- QA Team

Content
  +-- Writers
  +-- Editors
```

When you assign a human review node to "Engineering," all members of Frontend Team, Backend Team, and QA Team are eligible reviewers.

### Multi-Membership

A person can belong to multiple groups simultaneously. For example, a team lead might be in both "Engineering" and "Managers." They will receive review requests assigned to either group.

## Using Groups in Workflows

When configuring a human review node in the workflow designer, you select which group (or individual people) should receive the review request:

* **Universe**: Anyone in your account
* **Specific group**: Only members of that group
* **Individual people**: Specific named reviewers

This is how you control who reviews what. For example:

* Content moderation requests go to the "Content Moderators" group
* Legal review requests go to the "Legal Team" group
* Sensitive escalations go to specific senior reviewers by name

## Best Practices

> [accordion] Keep groups purpose-driven
>
> Create groups that map to review responsibilities, not organizational charts. A "Content Moderators" group is more useful than a "Marketing Department" group for assigning reviews.

> [accordion] Use nesting for hierarchy
>
> Nest sub-teams inside broader groups so you can assign reviews at the right level of granularity. Assign to the parent group when any sub-team member can handle it.

> [accordion] Ensure adequate coverage
>
> Each group that receives review requests should have at least 3 active members to ensure timely responses during off-hours or vacations.

> [accordion] Review membership regularly
>
> Remove people who are no longer active reviewers. Stale memberships lead to unread notifications and slower response times.

## Next Steps

> [card] [Workflows](https://docs.hitl.sh/concepts/workflows.md)
>
> Learn how workflows use groups for reviewer assignment

> [card] [Workflow Designer](https://docs.hitl.sh/guides/workflow-designer.md)
>
> Configure human review nodes with group assignment

> [card] [Responses](https://docs.hitl.sh/concepts/responses.md)
>
> Understand how responses are collected from reviewers

> [card] [Organizations](https://docs.hitl.sh/guides/organizations.md)
>
> Enterprise organization management


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.