State machines are product decisions

When software moves money or feeds people, the most important design is often a list of arrows. Which states exist, which moves are allowed, and what happens when someone tries an illegal one. In Djengo those lists are written down, enforced in code, and treated as product rules.

Payroll runs#

PENDING    → DRAFT
DRAFT      → PROCESSING | PENDING
PROCESSING → APPROVED | FAILED
APPROVED   → PAID
PAID       → CLOSED
FAILED     → DRAFT
CLOSED     → (terminal)

There is no path from PAID back to DRAFT. If a paid run was wrong, you fix it with a new run, and the history keeps both. Deductions are calculated per staff member and net pay is floored at zero, so a misconfigured deduction can never produce a negative salary.

Budgets can gate payroll

Orders and the kitchen#

PENDING → CONFIRMED → PREPARING → READY → SERVED
any non-terminal state → CANCELLED
SERVED → REFUNDED (manual override)

Restaurant, bar, and room-service orders create kitchen tickets automatically, routed to a station: main, bar, pastry, grill, or cold. The transitions mirror how a pass actually runs, which is why floor staff do not need training to read them.

Approvals#

1. 1If a company has an approval chain for an entity type, like leave requests, submitting creates an approval.
2. 2Steps run in order. Step N cannot be actioned until step N-1 is approved.
3. 3Any rejection closes the whole approval as rejected.
4. 4Each step notifies the next approver, and the final decision notifies the submitter.
5. 5No chain configured means auto-approve, so small teams are not punished with ceremony.

A state machine is a promise to the person on the other side of the screen. Accountants need to know a closed payroll stays closed. A chef needs to know a cancelled ticket will not reappear. Getting the arrows right is product work.