Assignment Workbench

You inherited a cluster where nobody labeled their workloads, and finance still wants per-team chargeback. The Assignment Workbench is the surface that solves this without forcing you to negotiate with twelve teams about a label convention. Open Cost Attribution → Assign, pick a Team, pick workloads, save. Repeat until the cluster is covered.

Layout

The Workbench is one page with three regions:

• The org sidebar on the left — your Teams and Departments, with a count of currently-assigned entities next to each name. Click a Team to scope the rest of the page to it.
• The Assigned tab — the workloads currently assigned to the selected Team. Filter, sort by cost, click a row to drill in.
• The Available tab — every workload visible to you that doesn't yet have an assignment matching the selected Team. This is where you pick workloads to add.

A detail pane on the right opens when you select a single workload, surfacing its cost, namespace, cluster, and current Team list.

Paginated and fast

The Assigned and Available tabs are paginated, not a single virtualized stream. Each tab fetches a slice of workloads at a time (with prefetch on hover). For organizations with thousands of workloads the experience is "paginated table with quick search and filters" — open the Team, page through, refine the filter, assign.

The page supports filter-driven narrowing: filter by namespace, cluster, controller kind, or current attribution state. You're meant to narrow first, then pick — not scroll through every workload.

Single assignment

Click a workload in the Available tab. The detail pane shows the workload. Pick a Team from the Team dropdown and save. A manual assignment is recorded and the workload moves from Available to Assigned on the next refresh.

If the workload was previously attributed by label to a different Team, the new manual assignment wins (see Label-based attribution). The label stays on the pod; it just doesn't drive attribution anymore.

Bulk assignment

Multi-select workloads in the Available tab with the checkbox column, then click the Assign dropdown above the table. Every selected workload gets the same Team assignment at once. Use this for "everything in this namespace belongs to this Team" sweeps after a re-org or when onboarding a new owner.

Bulk un-assign is the inverse: select assigned workloads, click Unassign, and every selected workload loses its manual assignment and falls back to label-based attribution (or unattributed if there's no label).

Cost splits — up to 10 Teams

Some workloads genuinely serve multiple owners. The cluster's ingress controller. A shared platform autoscaler. A bastion you don't want to pretend belongs to only one team. For those, use Split Cost.

Open the workload's detail and click Split Cost. A dialog opens with a per-row Team picker and weight field. Rules:

• Up to 10 teams per workload. The Add button is disabled once you've reached 10 rows.
• Weights are percentages summing to exactly 100. Any combination — 50/50, 60/40, 33/33/34, eight teams at 12.5% each, ten teams at 10%. Decimals are allowed.
• Each row becomes a weighted manual assignment. Cost Explorer's "by Team" view divides the workload's cost across the assignments by their weight.

To collapse a split back to single ownership, open Split Cost and remove all rows except one (set its weight to 100), or use Unassign to clear the workload and re-assign single-Team.

Cluster-level assignment

Some assignments are coarser than a workload. "Everything in cluster dev-east belongs to the Platform Team" is reasonable. From the org sidebar, pick the Team, then use the Cluster Assign panel to attach an entire cluster.

A cluster-level assignment uses safe defaults: it does not override workloads that already have their own (more specific) Team assignment. Manual per-workload assignments and label-based per-workload assignments take precedence over the cluster default. Use the cluster-level rule for the long tail of pods nobody specifically owns.

The same model is available for namespaces via Namespace Assign.

How assignments behave

Every action in the Workbench creates or removes a manual assignment. Manual assignments:

• Cover a workload, a namespace, or a cluster.
• Always win over label-based assignments for the same entity.
• Are never automatically removed — Kubeadapt's label sync only touches label-based assignments.
• Can be removed with Unassign, which falls back to label-based attribution (or "Unassigned" if no label is present).

Unassigning vs deleting

These are different actions:

• Unassign on a workload removes the manual assignment. The workload falls back to label-based attribution if a label is present; otherwise it shows as "Unassigned".
• Delete a Team is a Team-level destructive action (see Teams and Departments). It triggers the Unassign-and-Delete flow if the Team still owns any rows.

In the Workbench you'll almost always want Unassign. Team deletion lives on the Teams admin page.

Search and filter inside the tabs

Each tab has a search box plus standard filters:

• Search — substring match on workload name.
• Namespace — pick from the visible set.
• Cluster — pick from the visible set.
• Controller kind — Deployment, StatefulSet, DaemonSet, Job, CronJob.
• Attribution state — Available has "no manual assignment", "has label-driven", "has neither"; Assigned has "single team", "split", "by source".

Search and filters narrow the rows before you bulk-select. The most efficient workflow is filter first, multi-select, assign.

Next steps

• Teams and Departments — the data model the Workbench writes to.
• Label-based attribution — the automatic path that runs alongside the Workbench.
• Trace cost to a team — end-to-end attribution workflow.