ORGONAUT
Login Signup
Docs
Org model
Org units and hierarchy

Org units and hierarchy

In Orgonaut, hierarchy is modeled through org units.

Departments and teams are metadata entities, but org_units is the canonical tree used for structure, rollups, and scenario-safe comparisons.

Why this matters

If hierarchy is inferred from legacy foreign keys, results drift across views.

By anchoring hierarchy in org units, Orgonaut keeps these consistent:

  • Charts tree structure
  • Matrix grouping and filters
  • department/team rollups
  • scenario deltas and promotions

Mental model

  • org_units = the tree (company, department, team, and system nodes)
  • departments / teams = descriptive metadata
  • org_unit_actor = who sits where (placements)

A department or team can exist only as metadata, but it is not structurally meaningful until linked through its org unit node.

How hierarchy is edited in the UI

Hierarchy placement is managed through parent selection and drag/drop modeling tools.

Parent selector (forms)

When creating/editing teams or departments, use the parent selector to choose the parent org unit.

  • teams support parent validation by allowed parent types
  • departments support parent department selection (or root)

Visual modeling (charts/matrix edit mode)

In editable contexts, drag/drop operations create structured move commands that update hierarchy safely through the change tray workflow.

Scenario awareness

Hierarchy always resolves inside the active context:

  • Live baseline (scenario_id = NULL)
  • scenario context (scenario_id = active scenario)
  • snapshot context (read-only)

Never compare nodes across contexts by raw IDs alone. Lineage/original mapping is used internally for stable comparisons.

Safe hierarchy practices

  • model major structural moves in a scenario first
  • keep one clear department parent chain
  • avoid duplicate labels for sibling units when possible
  • review charts and matrix after each large reparenting wave

Common mistakes

  • using team or placement metadata as hierarchy source
  • treating team metadata as hierarchy without org unit context
  • mixing broad restructures with unrelated edits in one scenario