Skip to main content
This is the map of every document type the workflow engine drives — its path (states and the main transitions) and, where it has one, its approval gate and shipped default chain. Use it to see at a glance what a document does out of the box before you customise it in the editor. Conventions used below:
  • Start = the state a document begins in; end = a terminal (finished) state.
  • 🔒 system = a transition the system fires automatically — locked, not editable.
  • ⛩ gate = the approval step; this is where an approval policy attaches. Only these steps show the approver badge.

​
Three kinds of document

The eleven “Path + approval” document types are the ones you’ll spend most of your time on here.

​
Path + approval

These all follow the same core shape — Draft → submit → PendingApproval → approve → Approved — with post-approval stages that differ by document. The Approve step is the gate.

​
Expense (Accounting)

Draft → submit → PendingApproval → approve ⛩ → Approved → recordPayment → Paid (end). Also void (Approved → Void).
  • Reject returns it to Draft to revise and resubmit.
  • Default chain: none — auto-approves until you add a rule.

​
Invoice (Accounting)

Draft → submit → PendingApproval → approve ⛩ → Approved → send → Sent → part/full payment → PartiallyPaid / Paid (end). markOverdue is 🔒 system.
  • Reject → Draft. Default chain: none.

​
Bill (Accounting)

Draft → submit → PendingFinance → approve ⛩ → Approved → payment → PartiallyPaid / Paid (end). (The waiting state here is called PendingFinance.)
  • Reject → Draft. Default chain: none.

​
Budget (Accounting)

Draft → submit → PendingApproval → approve ⛩ → Active → close → Closed (end).
  • Reject → Draft. Default chain: none.

​
Journal Entry (Accounting)

DRAFT → submit → PendingApproval → approve ⛩ → POSTED → reverse → REVERSED (end). Every transition here is 🔒 system — journals are driven by the posting engine; a direct post can bypass approval for straight-through entries.
  • Reject → DRAFT. Default chain: none.

​
Quotation (Accounting)

Draft → submit → PendingApproval → approve ⛩ → Approved → send → Sent → accept / lose / revise / expire. All transitions 🔒 system.
  • Reject → Draft. Default chain: none.

​
Leave Request (HR)

Draft → submit → PendingApproval → approve ⛩ → Approved (end). Also cancel (before or, for approvers, after approval).
  • Reject → Rejected (end). Default chain: none.
  • A rule for leave can be scoped to a department (see Approval Policies).

​
Reimbursement (Personal finance)

Draft → submit → PendingApproval → approve ⛩ → Approved → pay → Paid (end). Also void.
  • Reject → Rejected. Default chain: none.
  • Supports a Payment step so the final sign-off also records the pay-out.

​
Salary Advance (HR / Advances)

Draft → submit → PendingApproval → approve ⛩🔒 → Approved → Disburse → Disbursed → StartRepayment → Repaying → Complete → Completed.
  • Reject → Rejected. The approve/reject gate is system-driven — only the approval engine completes it.
  • Default chain (shipped): HR Approval → Finance Approval.

​
Work / Field Advance (HR / Advances)

Draft → submit → PendingApproval → approve ⛩🔒 → Approved → Disburse → Disbursed → StartReconcile → Reconciling → Settle → Settled (end).
  • Reject → Rejected. Gate is system-driven.
  • Default chain (shipped): Manager Approval → Finance Approval → MD Approval.

​
Purchase Requisition (Procurement)

Draft → submit → PendingApproval → approve ⛩🔒 → Approved → MarkConverted → Converted (end); or PartiallyConverted. Cancel from PendingApproval.
  • Reject → Rejected. Gate is system-driven; conversion transitions are 🔒 system (fired when procurement raises the PO).
  • Default chain: none by default — add your requisition approvers.

​
Path only (no approval gate to configure)

These have a lifecycle you can view and lay out in the editor, but no approver badge — their transitions are governed purely by role.
  • Purchase Order (Procurement): Draft → submit → Submitted → approve → Approved → markSent → Sent → receiving → PartiallyReceived / Received (end). Reject → Draft. Receipt posting fires the 🔒 system receive transitions.
  • Payroll: Draft → generate → Generated → review → UnderReview → approve → Approved → pay → Paid (end).
  • Payment: DRAFT → post → POSTED → reverse → VOID. All 🔒 system.
  • Employment (HR): Active → end → Ended. Used when closing an employment record.
  • Imprest: a standalone imprest doctype (distinct from Work Advance): Draft → submit → PendingApproval → approve → Approved → disburse → Disbursed → submitAccountability → AccountabilitySubmitted → retire → Retired.
  • Employee Loan (HR): Applied → approve → Approved → disburse → Disbursed → start_repayment → Repaying → close → Closed.
  • CRM Lead: New → contact → Contacted → qualify → Qualified → convert → Converted (or Lost).
  • CRM Deal: Qualification → advance through Demo → Proposal → Negotiation → Ready to Close → win → Won (or Lost).
These may gain approval gates in future; today they are lifecycle-only.

​
Approval only

Some items are approvable but don’t have a visual state machine — they’re routed by the approval engine directly. These include Employee Transfer, Deal, Discount, Goal, Project, Payroll Run, Opening Balance Batch, Year-End Close, and Attendance / Shift / Compensatory-leave requests. They won’t appear as cards in the workflow catalog because there’s no path to draw; their sign-off is handled where the item itself is raised.

​
Roles you’ll see on transitions

The paths above reference workflow roles (e.g. FinanceApprover, Requester, LeaveApprover, POApprover). These are resolved from a user’s actual system roles — for example a user with a finance role automatically holds the finance workflow roles, a user with an HR role holds the HR/leave roles, and the person who created a document holds its “creator/requester” role. You can pin any of these roles to specific people with a role binding. The separate approver types used inside approval rules (Role, Specific User, Submitter’s Manager, Department Head, Permission) are described in Approval Policies.