---

summary: Hierarchical sub-teams + multi-membership — manage who belongs to which team and how teams nest.

OtiumWork's team model supports hierarchy (a parent team containing sub-teams) and multi-membership (one person belongs to many teams, each with a role). The legacy single-string employee.department field is still updated as a back-compat shim — every employee has exactly one primary team that mirrors into it.

Where

Admin → Teams (/admin/teams) — admin-only management.

Listing page

Shows every team in the company with its parent (or — for top-level), member count, manager count, and an "active / inactive" pill. A small form at the top creates a new team.

Per-team detail page

• Rename / change parent / delete (delete only allowed when the team has zero members and zero sub-teams)
• Members table with per-row controls:
• Role dropdown — member or manager (instant save)
• make primary — set this team as the employee's primary; clears any other primary they had + updates employee.department to this team's name
• Remove — pulls them off this team
• Add an employee form — pick from active company employees not already on this team, choose role, optionally make this their primary

Hierarchy example (SoftInWay, as of today)

AxSTREAM Development                  ← parent
  ├── AxSTREAM AI Development Team    ← sub-team
  └── AxSTREAM ION Development Team   ← sub-team

Valentyn Barannik is the manager of all three — assigned to AI as his primary, also a manager-rank member of ION and the parent.

Filtering by team in reports

When you pick a parent team in the report's department filter, the filter automatically expands to include every sub-team beneath it. Picking "AxSTREAM Development" matches anyone whose primary team is "AxSTREAM AI Development Team" or "AxSTREAM ION Development Team" too. Picking a sub-team directly matches only that sub-team's members.

What still uses the old employee.department field

Some readers (utilization rollups, optimization grouping, the employee-edit form) still read employee.department rather than employee_team. They keep working because the team admin UI mirrors the primary team's name into that field on every membership change. A future Phase 3 will migrate those readers to query employee_team directly.