Departments — organization hierarchy

In one sentence

The Departments admin page defines your organization's department hierarchy — a single tree of names with sub-departments nesting under their parents — that every scope-aware module (documents, audits, actions, MOC, etc.) reads from when filtering and routing records.

Three things to remember

One hierarchy, organization-wide. Departments are not per-facility. A Quality department exists once for your org; what differs per facility is which departments are present at that facility (configured at Settings → Facilities).
Sub-departments nest by parent. A department row can declare another department as its parent. The tree is what shows up in pickers — Quality / QA Lab, Quality / Inspection — so multi-level orgs stay legible.
Deactivate, don't delete. Active records and audit trails reference the department row. Toggling Active off hides the department from new pickers but keeps the existing references intact. Deleting is rare and you have to clear references first.

What's on the page

A single table showing every department with:

Name — the department label as users see it (Quality, Engineering, Operations).
Parent — optional; pick another department to nest this one under.
Active toggle — flip off to retire the department without breaking historical references.

A Show/hide inactive toggle filters the deactivated rows out of view when you're scanning. The header strip shows the count.

A Facilities link in the header takes you to Settings → Facilities, where you decide which departments are present at which sites — that's a separate concept from defining the department itself.

How nesting works

Each department row optionally carries a parent. When rendered in pickers across the app, departments are shown indented under their parent:

Quality
  QA Lab
  Inspection
  Calibration
Engineering
  Design
  Manufacturing Engineering
Operations
  Production
  Shipping

The hierarchy is purely presentational — there's no inherited permissions or routing semantics from a parent. QA Lab doesn't inherit Quality's rules. The tree exists to keep long picker lists comprehensible.

Department vs facility

The two concepts solve different problems and are intentionally separate:

Facilities are physical locations — buildings, sites, plants. They're managed at Settings → Facilities.
Departments are functional groupings — Quality, Engineering, Operations. Org-wide.

The mapping between them — "which departments exist at the Phoenix plant" — lives on the facility, not the department. A department added here doesn't automatically appear at every facility; the admin attaches the department to each facility where it's relevant via the facility_departments join (configured on the Facility detail page).

This is why a department picker on a record sometimes shows a subset of all org departments — it's filtered to the departments present at the record's active facility.

See Facility & Department Scope for the picker behavior.

Deactivating a department

Toggle Active off. The department:

Stops appearing in new pickers across the system.
Stays on existing records that reference it (a closed NCR scoped to Inspection keeps that scope even if Inspection is later deactivated).
Stays in this admin table — flip it back on at any time.

This is the right move when reorganizations rename or merge teams. The historical scope on past records remains accurate; new records use the new department names.

Who can change this

Admin-only — gated on the Access audit admin permission.

Facility & Department Scope — how the picker behavior works on records
Organization setup — the broader admin tour