Skip to main content
This page is the model behind groups. For the day to day actions, creating, renaming, moving and deleting them, see Groups.

​
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.
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:
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.

​
Assigning a supervisor

A supervisor account carries the same kind of path. Their scope is every user whose path contains theirs.
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.

​
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: 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.
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.
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.

​
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

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