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

# Groups and hierarchy

> How the group tree is stored, what nesting actually does, and how a group name ends up on a row of activity.

<Info>This page is the model behind groups. For the day to day actions, creating, renaming, moving and deleting them, see [Groups](/admin/groups).</Info>

## The tree

Groups form a tree beneath the organisation. A group has a name, a description, a parent, and the chain of ancestors above it. Depth is limited to six levels, which is more than any customer has used.

```
Lakeside Support Services      (organisation, not a group)
└── Athens                     (top level group, parent is the organisation)
    └── Team Aurora            (child, ancestors: Athens)
```

A user is assigned to a group by its **full path**, not just the group itself. Somebody in Team Aurora carries a path that names Athens and then Team Aurora.

That single design decision explains most of the behaviour people find surprising, so it is worth stating plainly:

<Info>**Scoping matches on the path, not on the group.** A supervisor assigned to Athens sees everyone in Athens and everyone in every team beneath it, because those people's paths contain Athens. Nothing has to be configured for the nesting to work.</Info>

## Assigning a supervisor

A supervisor account carries the same kind of path. Their scope is every user whose path contains theirs.

<Warning>Assign a supervisor to **exactly one** group. When an account carries more than one, the filter requires a user to match **all** of them at once, and since almost nobody is in two teams simultaneously, the supervisor sees nobody. For somebody who covers two teams, assign the nearest common parent instead. This is the most common cause of a supervisor reporting an empty dashboard.</Warning>

## How a group reaches a row of activity

When the client uploads a session it stamps the person's groups onto the row, as both names and identifiers, at the moment the row is written.

The consequences:

| Action                        | Effect on data                                                                                   |
| ----------------------------- | ------------------------------------------------------------------------------------------------ |
| Move a person to another team | New rows carry the new team. Old rows keep the team they were in at the time.                    |
| Rename a group                | New rows carry the new name from the next time each client signs in. Old rows keep the old name. |
| Move a group to a new parent  | User assignments and descendants follow automatically for future rows.                           |
| Delete a group                | Historic rows still carry its name. Any supervisor scoped to it sees nothing.                    |

This is deliberate. A report about last quarter describes the teams as they were last quarter, which is normally what you want. It does mean that a report spanning a rename will show both names, and that is not a bug to chase.

<Info>From client 8.0 the group name is read from the group itself each time a client signs in, so a rename reaches new activity as soon as machines next sign in. Earlier clients kept a copy of the name on the account, which could carry on stamping the old name onto new rows until the account was edited. If you renamed a group before the 8.0 rollout, that is why the old name may appear on rows written after the rename.</Info>

<Info>Anonymised rows, the ones for targets that are not on the corporate list, carry the group but no username. That is what makes a team-level total possible for non-work time without attributing it to a person. See [Corporate and non-corporate targets](/concepts/corporate-targets).</Info>

## Designing the tree

A few things that hold up in practice:

* **Mirror how the work is actually managed**, not the HR org chart. The tree's job is to make one supervisor's scope match one supervisor's responsibility.
* **Put sites or programmes at the top level and teams underneath.** It gives you a natural place to assign a supervisor who covers a whole site.
* **Use the description field.** It appears in brackets after the group name throughout the dashboard, and the supervisor's name in there answers "who runs this team" without anyone asking.
* **Do not create a group per person.** Groups are for aggregation. A group of one makes every report noisier and gives you nothing that filtering by user does not already do.

## Where the tree is visible

| Page                                          | Shows                                                               |
| --------------------------------------------- | ------------------------------------------------------------------- |
| **Workforce**                                 | The tree beside the account list, for assigning and editing         |
| **Hierarchy**                                 | The same structure as an organisation chart, easier to read at size |
| **Statistics**, **Activity**, **Data Export** | A group filter, which includes everything beneath the group chosen  |

***

*Checked against ReclaimTime client 8.0.0.9 and dashboard V3 on 5 September 2026.*