Departments and department types

Departments provide stable structure for planning, reporting, and governance.

Department types provide taxonomy so views and filters stay meaningful at scale.

What you can edit on a department

In the department create/edit flow, you can set:

name
department type (required)
parent department/org unit (optional)
cost center (optional)
lead actor (optional)
active/inactive status
description

Where department types are managed

Settings page: /settings/department-types

Types are tenant-scoped labels used for consistent categorization in charts, matrix, and reporting.

How parent placement works

Department hierarchy is not stored as parent_department_id.

Instead, the parent relationship is maintained by the linked org unit node. This keeps department hierarchy aligned with the canonical org tree.

Department lead and membership are different

lead_id indicates leadership ownership metadata.
Actual department membership comes from placements (org_unit_actor), not from lead or legacy foreign keys.

Scenario behavior

Department changes are context-aware:

in Live View, edits affect baseline
in scenario context, edits stay inside that scenario until promotion
in archived/snapshot contexts, editing is blocked

Good practices

define a small, stable set of department types
keep naming normalized (Engineering vs multiple variants)
use status/inactive flags rather than deleting historical structure too early
validate parent placement after restructures in charts view

Common mistakes

using type labels as hierarchy (types classify; they do not parent)
assuming lead metadata creates placement membership
letting duplicate department names drift across scenarios without clear intent