Teams and Departments

You opened Cost Attribution → Teams, you can see the names, but you want to know exactly what a Team is, what a Department is, and what happens when you delete one. This page is the conceptual reference — what Teams and Departments are, where they come from, and the lifecycle rules that govern how they're created, edited, and removed.

Teams

A Team is the unit cost rolls up to. Every assignment points at exactly one Team (or, in a split, multiple Teams with weights). A Team has a name, an optional description, an optional owner contact, and an optional parent Department. Kubeadapt also tracks when each Team last appeared in your cluster, so stale Teams stay discoverable in historical reports without polluting the live list.

Each Team is also tagged with where it came from:

• Created in-product — someone added the Team in the UI or via the admin API. It exists because someone wanted it to exist.
• Created from a label — Kubeadapt created the Team automatically when a new label value showed up on a workload. Run kubectl label deployment payments-api team=billing for the first time and a Team named billing will appear on the next cluster update.

Both kinds of Team live side by side and behave identically once created — the origin is metadata, not a permission boundary.

Departments

A Department is a group of Teams. The mapping is one-to-many: a Team belongs to zero or one Department; a Department contains zero or more Teams.

A Department has a name and an optional description, and tracks the count of Teams currently in it. Like Teams, Departments are tagged with their origin (created in-product or created from a label).

Departments don't own assignments directly — workloads are assigned to Teams, and the Department follows through Team membership. The Cost Explorer "by Department" view rolls up through Team membership.

Creating Teams and Departments

Two paths:

• Create in the UI. Cost Attribution → Teams → New Team (or Departments → New Department). Set name, description, owner email, optional parent department.
• Created automatically from a label. Add a label like team: payments to a pod for the first time and the next cluster update will create a payments Team automatically.

For Departments, label-driven creation requires the Department label key (defaults to kubeadapt-department) to be set in Settings → Label Keys and applied to pods. See Label-based attribution.

Deleting a Team

A Team that owns assignments cannot just disappear — the assignments would orphan their cost rows. Kubeadapt enforces this with the Unassign-and-Delete flow.

When you delete a Team that still has assignments, the product opens a two-step dialog:

1. Step 1 — Resolve the orphans. Pick a strategy for the assigned entities: unassign them all (workloads become unattributed) or bulk-reassign them to another Team.
2. Step 2 — Confirm the delete. The Team is removed after step 1's writes complete in the same transaction.

A Team with no assignments can be deleted directly. Deletion is honored permanently — if you delete a Team and the same label later reappears, Kubeadapt will not re-create the Team. From every UI and query, the Team is gone immediately.

Deleting a Department

A Department, unlike a Team, does not own assignments directly — its only relationship is to its child Teams. Deleting a Department therefore does not cascade through to assignments.

When you delete a Department with member Teams, the product surfaces this language verbatim:

Teams will not be deleted; they will become unassigned to any department.

Each of the child Teams stays — they just lose their Department. Their assignments are untouched. The Cost Explorer "by Department" view stops including them under the deleted Department and starts including them under the "Unassigned" Department bucket instead.

If you want to delete a Department and its Teams together, do it in order: delete (or reassign) each Team first, then delete the Department.

Renames are fast and safe

Renaming a Team or Department doesn't move any cost data — the relationship is stable across renames. The new name is reflected immediately everywhere. Finalized Reports keep the name that was active at finalization, so cited month-end numbers never drift after a rename.

Last-seen and stale Teams

When a label-created Team stops appearing in your cluster — the last team: foo label was removed — the Team is not deleted. It stays with its Last seen date set to when it was last observed. This lets historical Reports stay readable and lets you find old Teams whose last appearance was long enough ago that you might want to clean them up.

If the label later reappears, Kubeadapt will silently re-create the same Team. To prevent that, delete the Team explicitly in the UI — once you've done that, Kubeadapt will not re-create the Team even if the label comes back.

Next steps

• Assignment Workbench — the place to point Teams at workloads.
• Label-based attribution — the automatic path and how it stays in sync.
• Cost attribution overview — the three-layer model.