> ## Documentation Index
> Fetch the complete documentation index at: https://docs.hitaji360.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Workflows & Approvals — Overview

> How the two layers fit together — the workflow decides a document's path, the approval policy decides who signs off.

Almost every document you create in Hitaji 360 has a **life** — it starts as a draft,
gets submitted, is reviewed and approved (or sent back), and finally reaches a settled
end state. Two things control that life:

1. **The workflow** — the *path* a document takes: the named states it can be in
   (Draft, PendingApproval, Approved, …) and the arrows (transitions) between them,
   each of which only certain people are allowed to pull.
2. **The approval policy** — the *sign-off rule* attached to an approval step: **who**
   has to approve, **in what order**, above **what amount**, and what happens if nobody
   is configured.

For years these were two separate ideas in two separate screens ("Workflows" and
"Approvals"), and it was never clear how they fit together. They are now **one screen
and one mental model**: you pick a document type, you see its path, and you click the
approval step to say who signs it off.

> 📷 *Screenshots are added in a later pass. For now each page names the exact route
> (e.g. `/settings/erp/organization/workflows`) and the on-screen buttons to click.*

***

## The two layers, in plain terms

Think of a single expense claim.

* **The workflow (the path)** says: an expense starts in **Draft**; from Draft someone
  can **Submit** it, which moves it to **PendingApproval**; from PendingApproval it can
  be **Approved** (→ Approved) or **Rejected** (→ back to Draft). Those states and
  arrows are the workflow.
* **The approval policy (the sign-off)** hangs off the **Approve** arrow. It says, for
  example: *"claims up to UGX 500,000 need the submitter's manager; anything above also
  needs Finance."* That is the approval policy.

The workflow is the same for everyone on your tenant. The approval policy is set
**per business** (per accounting book), because different businesses sign off
differently.

```
        submit                approve
 Draft ─────────▶ PendingApproval ─────────▶ Approved
   ▲                     │
   └─────── reject ──────┘
                         ▲
                         │  ← the approval policy lives on this "approve" step:
                            who signs, in what order, above what amount
```

***

## Why it affects the whole ERP

This isn't only an accounting feature. The **same engine** drives the lifecycle and
sign-off of documents across modules:

* **Accounting** — expense claims, invoices, bills, journal entries, budgets, credit
  and debit notes.
* **Procurement** — purchase requisitions, purchase orders, purchase receipts.
* **HR** — leave requests, employee transfers, salary advances, work (imprest)
  advances, payroll runs.
* **CRM & projects** — deals, discounts, quotes, goals, projects.

Wherever you see a document sitting in **PendingApproval**, it is this feature deciding
who can move it forward. Configure it once here and every module obeys the same rules.

For the exact states and default approvers of each document type, see the
**[Document Types Reference](/workflows/user/document-types-reference)**.

***

## Two engines, one experience (for the curious)

Under the hood there are still two cooperating engines — you never have to think about
this, but it explains the behaviour:

* The **lifecycle engine** owns the states and transitions (the path). It enforces that
  only allowed roles can pull an arrow, and that a document can't jump to an illegal
  state.
* The **approval engine** owns the sign-off. When a document is submitted, it creates an
  **approval request**, works out the next approver from your policy, and notifies them.
  When the last approver signs off, it tells the lifecycle engine to move the document
  to **Approved** (or **Rejected**).

So a submit does two things at once: it enters **PendingApproval** *and* it kicks off
the approval chain. You configure both on the one screen; the app keeps them in step.

***

## What you'll do here

| Task                                                     | Where                                                                |
| -------------------------------------------------------- | -------------------------------------------------------------------- |
| Understand the screen and how to reach it                | [Accessing Workflows & Approvals](/workflows/user/accessing)         |
| Design a document's path (states & transitions)          | [The Workflow Editor](/workflows/user/the-workflow-editor)           |
| Say who approves, in what order, above what amount       | [Approval Policies](/workflows/user/approval-policies)               |
| Point a role at specific people                          | [Role Bindings](/workflows/user/role-bindings)                       |
| See every document type's states & default approvers     | [Document Types Reference](/workflows/user/document-types-reference) |
| Know what submitters and approvers experience day to day | [How Approvals Work Day to Day](/workflows/user/how-approvals-work)  |

***

## A few ground rules worth knowing up front

* **You rarely have to build anything from scratch.** Every document type ships with a
  sensible default path and, for the ones that need sign-off, a sensible default
  approval chain. If you change nothing, everything behaves exactly as it does today.
* **Some steps are locked.** A few transitions are driven by the system itself (for
  example, the automatic *Approve* that fires when the last approver signs off). These
  show a **lock** icon and can't be edited or deleted — that's deliberate; they're the
  contract that keeps your documents consistent.
* **You can always reset.** Any document type you've customised can be put back to its
  factory default with one click (**Reset to default**).
* **Approval policies are per business.** Make sure the correct business is selected in
  the business switcher at the top of the app before you edit who approves.