@sparkerp/plugin-sdk 0.1.0 → 1.1.0

package/bundle/docs/applications/hcm/leave-setup.md

@@ -0,0 +1,30 @@
+---
+title: Leave Types & Leave Policies
+audience: tenant
+---
+
+# Leave Types & Leave Policies (HCM)
+
+This page documents two shipped **Leave Management** setup screens
+(`hcm-leave`). Not for plugin developers.
+
+**Who this is for:** HR administrators setting these up, usually once
+(then revisited when policy changes).
+
+## Leave Types
+
+Define the kinds of leave your company offers (e.g. Annual, Sick,
+Unpaid) — the foundation everything else in Leave Management is built on.
+
+## Leave Policies
+
+For each leave type, configure entitlement, accrual, carry-forward,
+encashment, eligibility, and approval rules — scoped to specific employee
+groups if needed. Activating a policy checks for overlap with existing
+policies, changes go through a real approval workflow, and each version of
+a policy is kept, not overwritten.
+
+## Related
+
+- [Leave Requests](./leave-requests.md)
+- [Leave Balance](./leave-balance.md)

package/bundle/docs/applications/hcm/leave-team-and-calendar.md

@@ -0,0 +1,25 @@
+---
+title: Team Leave & Leave Calendar
+audience: tenant
+---
+
+# Team Leave & Leave Calendar (HCM)
+
+This page documents two shipped **who's off** screens (`hcm-leave`), for
+managers and HR planning around leave. Not for plugin developers.
+
+## Team Leave
+
+A manager/HR view of your team: **Team Members**, **On Leave Today**,
+**Pending Approvals**, **Upcoming**, and leave balance visibility across
+the whole team at a glance.
+
+## Leave Calendar
+
+A month-grid view of everyone's leave, overlaid on a calendar so you can
+see at a glance who's off on any given day. Currently month view only —
+there's no week, day, timeline, or year view yet.
+
+## Related
+
+- [Leave Requests](./leave-requests.md)

package/bundle/docs/applications/hcm/navigation-and-approvals.md

@@ -0,0 +1,61 @@
+---
+title: HCM Navigation & Approvals
+audience: tenant
+---
+
+# HCM Navigation & Approvals (HCM)
+
+This page documents the shipped **navigation shell** and **approvals**
+screens (`hcm-foundation`) that every HCM user sees, regardless of which
+specific module they work in. Not for plugin developers.
+
+## The app shell
+
+Every HCM page shares the same header and side navigation. The side
+navigation is a real menu, built from whatever HCM modules are actually
+installed for your tenant — it's not hand-maintained per page, so a newly
+installed module's menu items appear automatically.
+
+## The Apps screen
+
+Tapping **Apps** opens a dedicated, full-screen menu of every module and
+its pages, organized as icon-based tiles with submenus — similar to a
+phone's home-screen app grid. This is separate from, and more thorough
+than, the small "My Apps" launcher available elsewhere in the platform.
+
+## Approvals — three screens, two flavors each
+
+HCM has three approval-related screens, and each one comes in two
+variants depending on which part of HCM you're looking at (an
+**Organization & Job Classification** variant and an **Employee &
+Position** variant) — the same screen, applied to two different kinds of
+requests.
+
+### My Requests
+
+Everything **you've** submitted for approval — any status (pending,
+approved, rejected) — with KPI counts at the top.
+
+### My Approvals
+
+Everything waiting for **you** to approve, with real due dates:
+
+- **Due Date** and **Overdue** — every request has a due date (a 3-day
+  turnaround target applied uniformly across every request type in HCM, not
+  tuned per request type).
+- **Approved This Week**
+- **Delegated to me** — requests someone else forwarded to you.
+
+### All Requests
+
+Every request from every requester, any status — the same view as My
+Requests but without the "just mine" filter, plus a **Requester** column
+and a **Rejected** KPI. This is the one to check if you need to see
+everyone's requests, not just your own (typically for HR staff with
+broader visibility, not everyday employees).
+
+## Known gaps
+
+- **The 3-day approval SLA is uniform**, not tuned per request type — a
+  simple leave request and a complex compensation change both get the same
+  due-date window today.

package/bundle/docs/applications/hcm/offboarding-and-exit.md

@@ -0,0 +1,71 @@
+---
+title: Resignation, Retirement, Termination & Exit
+audience: tenant
+---
+
+# Resignation, Retirement, Termination & Exit (HCM)
+
+This page documents the shipped **offboarding** screens (`hcm-employee`) —
+what happens when someone leaves the company, whether by choice,
+retirement, or employer-initiated termination. Not for plugin developers.
+
+> **Important — there's a second, separate Resignation/Exit implementation.**
+> The `hcm-separation` module ships its own independent Resignation and
+> exit-process screens on different underlying tables — see
+> [Resignation & Resignation Approval (Separation module)](./separation-resignation.md).
+> The two don't share data. If your company uses this Employee-module
+> flow, be consistent about it rather than mixing the two.
+
+## The three exit types — HR admin screens
+
+Each of the three ways someone can leave has its own full screen for HR:
+
+### Resignation
+
+Notice period, multi-stage approval, the ability to withdraw a
+resignation, notice-period adjustment, handover, documents, and
+acknowledgements — plus an **Initiate Separation** action that hands the
+case off into Exit Management once it's finalized.
+
+### Retirement
+
+Age/service eligibility checking, notice period, multi-stage approval
+(Manager → HR → Finance), the option to defer, a pre-retirement checklist,
+knowledge transfer, and benefits/entitlements — with the same handoff into
+Exit Management.
+
+### Termination
+
+Employer-initiated: notice period, multi-stage approval (Manager → HR →
+Finance), an exit checklist, knowledge transfer, and documents — same
+handoff into Exit Management.
+
+## Employee self-service — "My ..." screens
+
+Matching self-service versions for the employee themselves:
+
+- **My Resignation** — see your own status, notice period, handover and
+  clearance progress, documents, and approval timeline. **Withdraw** your
+  resignation, or, if you don't have one on file, submit a new one.
+- **My Retirement** — a read-only view of your retirement info, timeline,
+  checklist, knowledge transfer, and tentative benefits/entitlements.
+- **My Termination** — read-only, since termination is employer-initiated:
+  you can see your termination ID, date, last working day, notice period,
+  and type, but there's no submit or withdraw action (there wouldn't be).
+
+## Exit Management
+
+Once any of the three exit types is approved, this screen automatically
+gets a real clearance record broken into HR, Finance, IT, Admin, Manager,
+and Asset Management — each area clears the departing employee
+independently, and this is where you track that.
+
+## Separation
+
+The underlying, company-wide record tying an exit together — a smaller,
+gated screen behind the scenes of the flows above.
+
+## Related
+
+- [Employee Profile](./employee-profile.md)
+- [HCM Navigation & Approvals](./navigation-and-approvals.md)

package/bundle/docs/applications/hcm/onboarding-documents-verification.md

@@ -0,0 +1,43 @@
+---
+title: Document Collection & Employee Verification
+audience: tenant
+---
+
+# Document Collection & Employee Verification (HCM)
+
+This page documents two shipped **Onboarding** screens (`hcm-onboarding`).
+Not for plugin developers.
+
+## Document Collection
+
+Request a document from a new joiner. Uploads are real — the file lands
+in your tenant's document storage (a real "HCM Onboarding Documents"
+folder, created automatically) — not a placeholder. From a document's
+detail view: **Verify**, **Reject**, **Request Resubmission**, **Waive**,
+**Cancel**, or **Download**, each recorded in a real history log.
+
+There's no document versioning — re-uploading a file replaces it in
+place, it doesn't keep the old version alongside the new one.
+
+## Employee Verification
+
+Open a verification case for a new joiner, then add individual checks
+underneath it (e.g. Identity, Employment). For each check, **Record
+Decision** — status, result, a failure reason if it didn't pass, who
+reviewed it, and comments. As you decide checks, the case's own overall
+progress % and result are recalculated automatically — you don't total it
+up yourself.
+
+## Known gaps
+
+- **Verification is single-reviewer** — the original design describes a
+  multi-party Reviewer → HR Manager → Compliance chain for high-risk
+  checks, but that isn't built; one person's decision closes a check.
+- **No versioning on documents** — see above.
+- **A check's supporting evidence is a freeform reference**, not
+  formally linked to Document Collection, even though you can point it at
+  a document by typing a reference to it.
+
+## Related
+
+- [New Joiners & Onboarding Dashboard](./onboarding-overview.md)

package/bundle/docs/applications/hcm/onboarding-orientation-probation.md

@@ -0,0 +1,65 @@
+---
+title: Orientation & Probation
+audience: tenant
+---
+
+# Orientation & Probation (HCM)
+
+This page documents two shipped **Onboarding** screens (`hcm-onboarding`).
+Not for plugin developers.
+
+## Orientation
+
+Schedule an orientation session for a new joiner — 16 real session types,
+4 delivery modes. **Start** it, record real-time **Attendance** (marking
+someone a No-Show automatically flips the session's own status, you don't
+also have to change the status separately), **Complete** it (accepts a
+partial-completion percentage — under 100% marks it Partially Completed
+rather than fully Completed), or **Cancel**/**Reschedule** (both require a
+reason). **Send Reminder** logs a reminder without changing status.
+**Feedback** records a single overall rating and comments.
+
+## Probation
+
+Start a probation period for a new joiner — duration defaults to 90 days
+if you don't set one, and there's a hard rule against starting two active
+probations on the same onboarding. As the period runs, **progress %** is
+calculated for you from how far you are between the start date and the
+current end date — no manual updates needed.
+
+Move it through **Start Review** → **Submit Review** (recorded separately
+for Manager and HR — both fields exist even though today the same person
+usually completes both, so a future pass can route them to two different
+people without a data model change) → **Confirm** or **Fail**. If more
+time is needed, **Request Extension** (reason and number of days
+required) pushes the end date out and tracks how many times it's been
+extended. **Terminate** is only available once a probation has already
+Failed — it's a real, deliberate boundary: this only flags the record,
+the actual termination process itself belongs to
+[Resignation, Retirement, Termination & Exit](./offboarding-and-exit.md).
+
+## Known gaps
+
+- **No configurable probation-policy hierarchy** — duration/dates are set
+  directly when you start a probation (default 90 days), not resolved
+  from a policy based on role/department/country.
+- **Probation's confirmation isn't a real routed approval workflow** —
+  it's a permission-gated sequence one role can complete end to end, even
+  though Manager and HR recommendations are tracked as separate fields
+  (a deliberate hook for a future real workflow, not yet used that way).
+- **No reusable orientation program/session-template system** — every
+  session is scheduled directly, not auto-assigned from a program.
+- **Manager Name on a probation record is free text**, not looked up from
+  a real employee search.
+
+> **Note:** this is the onboarding-scoped probation record for a new
+> joiner. There's also a separate, employee-wide
+> [Confirmation](./onboarding-to-confirmation.md) screen in the Employee
+> module — if you're not sure which one you need, Confirmation is the
+> broader, company-wide view; this one is specifically part of a new
+> joiner's onboarding journey.
+
+## Related
+
+- [New Joiners & Onboarding Dashboard](./onboarding-overview.md)
+- [Onboarding — Prejoining, Joining & Confirmation](./onboarding-to-confirmation.md)

package/bundle/docs/applications/hcm/onboarding-overview.md

@@ -0,0 +1,47 @@
+---
+title: New Joiners & Onboarding Dashboard
+audience: tenant
+---
+
+# New Joiners & Onboarding Dashboard (HCM)
+
+This page documents two shipped **Onboarding** screens (`hcm-onboarding`)
+— the entry points into the whole module. Not for plugin developers.
+
+> **Where this fits:** Onboarding is deliberately scoped to what happens
+> **after** someone's first day — once they're marked active via the
+> [Joining](./onboarding-to-confirmation.md) process in the Employee
+> module. If you're looking for pre-hire readiness or the actual Day-1
+> activation, that's Prejoining/Joining, not here.
+
+## New Joiners
+
+Your operational workspace for everyone currently going through
+onboarding — one row per onboarding record. Each row shows real Status
+(Not Started / In Progress / At Risk / Completed / Closed / Cancelled)
+and Risk (Normal / At Risk / High Risk / Critical) — risk is calculated
+automatically: an overdue pending checklist item flips a record to At
+Risk on its own, you don't have to notice it yourself.
+
+Click a row to open its detail: **Start**, **Complete**, **Close**, or
+**Cancel** the onboarding (each of the last three needs a reason), plus
+**Generate Checklist** to create a real checklist instance from a
+template. You can select multiple rows and use **Start Selected** to kick
+off onboarding for several new joiners landing at once — a real, common
+coordinator task.
+
+## Onboarding Dashboard
+
+KPI cards: Not Started, In Progress, At Risk, Completed This Month, Total
+Onboarding records, plus how many checklist items are pending/overdue
+across everyone — a real-time operational view, not a static count.
+
+## Known gaps
+
+- **Bulk actions are limited to Start** — Complete/Close/Cancel all need
+  a real reason or completion context per record, so they're deliberately
+  not offered as bulk operations.
+
+## Related
+
+- [Onboarding Templates & Checklists](./onboarding-templates-checklists.md)

package/bundle/docs/applications/hcm/onboarding-provisioning-assets.md

@@ -0,0 +1,48 @@
+---
+title: Account Provisioning & Equipment/Assets
+audience: tenant
+---
+
+# Account Provisioning & Equipment/Assets (HCM)
+
+This page documents two shipped **Onboarding** screens (`hcm-onboarding`)
+covering what a new joiner needs before or on day one. Not for plugin
+developers.
+
+## Account Provisioning
+
+Request a system or account for a new joiner (14 real account types —
+identity/IAM, ERP, email, and more). If you mark a request as needing
+approval, **Start** is blocked until someone **Approves** it first — a
+real, if simple, gate. From there: **Activate** (records the real account
+name and external ID once it exists), **Fail**/**Retry** (retries are
+capped by a max-attempts count, not an unlimited retry loop),
+**Suspend**/**Reactivate**, **Deactivate**, **Cancel**.
+
+## Equipment & Assets
+
+Request equipment for a new joiner (20 real categories). Walk it through
+**Allocate** (asset tag required) → **Schedule Delivery** → **Deliver** →
+**Acknowledge** (the recipient confirms receipt, condition required) →
+**Return Request** → **Return** — or **Report Damage** / **Report Loss**
+at any point along the way. Every step is logged to a real history.
+
+## Known gaps
+
+- **Neither screen actually provisions anything for real** — there's no
+  IAM/SSO connector, no live account creation, no asset-inventory system
+  behind these. Activating an account records what you type (a name, an
+  external ID); allocating equipment records an asset tag you type. These
+  are tracking/confirmation screens for IT/Facilities to record what's
+  been done, not systems that do the provisioning themselves.
+- **No multi-party approval routing** — Account Provisioning's single
+  approval toggle is the only approval concept here; there's no
+  Manager → Application Owner → Security chain.
+- **No reusable request bundles** — a "standard new-hire laptop + badge +
+  email" bundle has to be requested item by item, not as one preset.
+- **Nothing is auto-generated from a new joiner's role/department** —
+  every request starts from the dialog here, manually.
+
+## Related
+
+- [New Joiners & Onboarding Dashboard](./onboarding-overview.md)

package/bundle/docs/applications/hcm/onboarding-reports.md

@@ -0,0 +1,38 @@
+---
+title: Onboarding Reports
+audience: tenant
+---
+
+# Onboarding Reports (HCM)
+
+This page documents the shipped **Onboarding Reports** screen
+(`hcm-onboarding`) — the reporting hub for everything else in the module.
+Not for plugin developers.
+
+## What you see
+
+- A **Key Metrics** card — 11 real KPIs, spanning both onboarding-level
+  counts and cross-module completion percentages (e.g. what fraction of
+  documents across every active onboarding are actually verified).
+- Four report cards — **Department Report**, **Onboarding Status
+  Breakdown**, **Overdue Onboarding**, and **Exceptions** — each pulling
+  real, live data.
+- An **Onboarding Summary** section with its own drill-down grid over
+  every onboarding record; click a row for a quick detail view.
+
+**Exceptions** surfaces overdue onboarding, rejected documents, failed
+verifications, failed account provisioning, orientation no-shows, and
+failed probations, all in one merged list.
+
+## Known gaps
+
+- **Every number here is computed live on page load**, not cached or
+  scheduled — there's no saved-report, scheduled-email, or async-export
+  system behind this.
+- **Exceptions only covers categories backed by real tracked data** —
+  things like "Manager Action Overdue" or "Workflow Failure" aren't
+  listed because nothing in this module tracks that data yet.
+
+## Related
+
+- [New Joiners & Onboarding Dashboard](./onboarding-overview.md)

package/bundle/docs/applications/hcm/onboarding-templates-checklists.md

@@ -0,0 +1,38 @@
+---
+title: Onboarding Templates & Checklists
+audience: tenant
+---
+
+# Onboarding Templates & Checklists (HCM)
+
+This page documents two shipped **Onboarding** screens (`hcm-onboarding`)
+covering how onboarding tasks are planned and tracked. Not for plugin
+developers.
+
+## Onboarding Templates
+
+Build a reusable checklist template: a header plus ordered items, each
+with its own sequence, whether it's mandatory, an owner role, and how
+many days it's due within. **Manage Items** opens a dedicated
+add/edit/delete flow for the items themselves, separate from editing the
+template header.
+
+An onboarding can have several checklists running at once against
+different templates (e.g. one for Employee tasks, one for IT, one for
+Manager) — a template is scoped by checklist type (12 real types) and
+optionally by employment type, department, or location, so the right
+template gets picked automatically depending on who's onboarding.
+
+## Onboarding Checklists
+
+Two things in one screen: a read-only list of templates (create new ones
+from Onboarding Templates above), and each new joiner's own checklist
+*instance* — the actual cloned copy of a template's items for that one
+person. Mark an item **Complete** or **Skip**; either one recalculates
+that checklist's own progress and status, and rolls up into the parent
+onboarding's overall progress and risk status (an overdue item is what
+flips an onboarding to At Risk).
+
+## Related
+
+- [New Joiners & Onboarding Dashboard](./onboarding-overview.md)

package/bundle/docs/applications/hcm/onboarding-to-confirmation.md

@@ -0,0 +1,45 @@
+---
+title: Onboarding — Prejoining, Joining & Confirmation
+audience: tenant
+---
+
+# Onboarding — Prejoining, Joining & Confirmation (HCM)
+
+This page documents three connected shipped screens (`hcm-employee`)
+covering a new hire's journey from accepting an offer through to becoming
+a confirmed employee. Not for plugin developers.
+
+## Employee Lifecycle (overview)
+
+The starting point: a **KPI row** (Total, New Hires, In Progress,
+Transitions, Exits), six **stage cards** — Onboarding, Probation, Active,
+Inactive, Transition, Exit — and a donut breakdown showing where everyone
+currently sits, plus **Key Insights** and **Upcoming Actions** panels.
+There's no pre-hire "Recruitment" stage shown yet, since Recruitment
+doesn't have a candidate record to hand off from.
+
+## Prejoining
+
+Tracks someone from **offer acceptance** through to being ready to join —
+a KPI row, a grid, and a workflow/checklist panel walking through what
+still needs to happen before day one.
+
+## Joining
+
+Picks up once someone is marked ready to join in Prejoining, and covers
+the actual joining-day process through to the employee record becoming
+active.
+
+## Confirmation
+
+A company-wide, read-only view of confirmation status (i.e. who's still on
+probation vs. confirmed). You don't submit a new confirmation or extension
+from this screen — that's done from the employee's own
+[Profile](./employee-profile.md) or from the Probation Employees roster
+view; this page is where you check status across everyone.
+
+## Related
+
+- [Employee Profile](./employee-profile.md)
+- [Employee Directory & Rosters](./employee-directory.md) (Probation
+  Employees view)

package/bundle/docs/applications/hcm/org-structure.md

@@ -0,0 +1,53 @@
+---
+title: Reporting Structure & Organization Structure
+audience: tenant
+---
+
+# Reporting Structure & Organization Structure (HCM)
+
+This page documents two related but separate shipped screens
+(`hcm-employee`) — one shows who reports to whom, the other shows your
+department/unit hierarchy. Not for plugin developers.
+
+## Reporting Structure (org chart)
+
+Shows employees as a tree by manager, starting from the top and expanding
+as you click — it doesn't load your whole company's org chart at once, only
+the parts you actually open.
+
+- An **"Employees Without Manager"** count, so you can spot anyone who
+  isn't assigned a manager yet.
+- Click any employee to see their details, including who their Reporting,
+  Functional, and Dotted-line managers are (by name, not just an ID).
+- You can edit an employee's secondary (functional/dotted-line) managers
+  directly from here.
+- **Changing someone's main Reporting Manager isn't done here** — drag the
+  employee to a new manager on the chart itself (this needs the
+  `employee.manager-change` permission), or use Internal Movement with
+  movement type "manager" for a tracked change instead.
+
+## Organization Structure
+
+A separate, department-focused view: a card-based tree of your
+departments/units (not people), each card showing that unit's name,
+connected with lines to its parent unit.
+
+- A **KPI bar**: Departments, Total Employees, Span of Control, Open
+  Positions — all real, live counts.
+- Click any unit card to open a details panel with three tabs: **Details**
+  (unit type, location, cost center, description), **Members**, and
+  **Metrics**.
+- A legend at the bottom explains the card coloring/icons.
+
+## Known gaps
+
+- On Organization Structure: the **Chart** and **List** view modes (an
+  alternative to the default Tree view), **Export**, **Add Unit**, **Edit
+  Unit**, drag-and-drop reorganization, and **Expand All/Collapse All** are
+  all visible but disabled — planned, not yet built. You can browse and
+  view details today; you can't restructure departments from this screen
+  yet.
+
+## Related
+
+- [Employee Directory & Rosters](./employee-directory.md)

package/bundle/docs/applications/hcm/org-units.md

@@ -0,0 +1,86 @@
+---
+title: Org Units, Legal Entities, Business Units, Divisions, Branches, Departments, Locations, Cost Centers & Profit Centers
+audience: tenant
+---
+
+# Org Units and its typed views (HCM)
+
+This page documents the shipped **Org Units** screen (`hcm-organization`)
+and eight more screens that are all, underneath, the exact same
+organizational-unit data, just pre-filtered to one type each — the same
+"one real screen, several locked views" pattern as the
+[Employee Directory & Rosters](./employee-directory.md). Not for plugin
+developers.
+
+## Org Units (the general screen)
+
+**Getting there:** Organization → Org Units.
+
+### What you see
+
+- **KPI cards**: Total Units, Active Units, Departments, Employees Mapped.
+- A **hierarchy tree** on the left ("Organization Hierarchy") — click a
+  node to scope the grid to it and its children; **Show All Units** clears
+  that scope.
+- **Search** (by name or code) and a **Status** filter (All / Active /
+  Inactive / Draft / Pending Approval / Rejected) and **Unit Type** filter,
+  with a **Clear Filters** button.
+- A grid with columns: Unit Name, Unit Code, Unit Type, Parent Unit,
+  Location, Cost Center, Head of Unit, Employees, Status, Effective From,
+  and row Actions (View / Edit / Delete).
+- **Bulk actions** on selected rows: Activate, Deactivate, Delete (deleting
+  a unit that has child units or mapped employees/positions is skipped and
+  reported as a failure, not silently forced through).
+
+### Adding or editing a unit
+
+**Add Organization Unit** opens a form: Unit Name, Unit Code, Unit Type
+(Company / Business Unit / Department / Division / Branch / Location /
+Floor / Office / Work Location / Cost Center / Profit Center / Legal
+Entity / Country), Parent Unit (or "None (top level)"), Head of Unit,
+Manager Position, Description, Status (starts as Draft), Effective From,
+Effective To, and an optional **Apply Change On** date if you want the
+change scheduled rather than immediate. A banner appears on the record if
+the change is pending approval, telling you it'll apply once approved.
+
+### Unit detail
+
+Click a unit to open its detail view, with three tabs — **Overview**,
+**Validity**, **Workforce** — covering Organization, Business Unit,
+Company, Parent Unit, Child Units, Location, Cost Center, Head of Unit,
+Manager Position, Employees, Positions, Vacancies, Effective From/To,
+Created By, and Last Updated By. From here: **Edit**, **View Employees**,
+**View Positions**, **View Org Chart**.
+
+## The typed views
+
+Eight more screens in the HCM menu are the same underlying columns and
+actions as Org Units above, pre-filtered and locked to one unit type, so
+each has its own focused screen instead of you filtering Org Units by
+hand every time:
+
+| Screen | Unit type |
+|---|---|
+| **Legal Entities** | Legal entity |
+| **Business Units** | Business unit |
+| **Divisions** | Division |
+| **Branches** | Branch |
+| **Departments** | Department |
+| **Locations** | Location (and location sub-types like floor) |
+| **Cost Centers** | Cost center |
+| **Profit Centers** | Profit center |
+
+Each typed view has its own grid (Name, Type, Location, Head of \<Type\>,
+Employees, Status, Actions) and its own create/edit form — you don't need
+to also filter by type since it's locked to the one you opened.
+
+## Known gaps
+
+- **Deleting a unit is blocked, not cascaded** — a unit with children or
+  mapped employees/positions can't be deleted from here; you'd need to
+  reassign or remove those first.
+
+## Related
+
+- [Organizations](./organizations.md)
+- [Reporting Structure & Organization Structure](./org-structure.md)