Approval Worked Examples
This page follows three real purchase orders through a three-level approval chain — one approved, one rejected, one raised by somebody outside the chain. Each shows the setup behind it, what each person sees, and the approval log the transaction ends up carrying. The figures and timestamps are from a demonstration company.
The setup these examples use
One rule, on Purchase Order, with three of the five levels filled in:
| Level | Designation group | Who is in it | Role in the chain |
|---|---|---|---|
| Top — First | Finance Head | Meena Sundar | Finalises the order |
| Second | Purchase Manager | Karthik Selvam | Approves before it reaches Finance |
| Third | Purchase Buyer | Priya Raman | Raises the order |
| Fourth | — not used — | ||
| Fifth — Lowest | — not used — |
Approval climbs. The order is raised at the lowest filled level and moves up one level at a time until Top signs it off. See Approval Setup for how this is entered.
Example 1 — an order that goes through
Purchase Order 071/2026, raised for a supplier by the buyer.
| Time | Who | Level | What they did | Log status |
|---|---|---|---|---|
| 20:25 | Priya Raman | Third | Raised the order and saved it | Created |
| 20:30 | Karthik Selvam | Second | Opened it, checked the prices, approved | Approved |
| 20:30 | Meena Sundar | Top | Approved — the order is now live | Approved |
What each person saw
| Person | What happened on their screen |
|---|---|
| Priya (buyer) | Saved the order as normal. It appears in Approval with status Pending. She cannot push it any further herself. |
| Karthik (manager) | Got a notification — Approval is ready. Awaiting your permission to proceed. The order appeared in his Approval list. He opened it from the reference, checked it and approved. |
| Meena (Finance Head) | Was notified the moment Karthik approved, not before. She approved, which closed the chain. |
Notice that Meena was not told about the order while it was still with Karthik. Each approval notifies only the next level up, so a Finance Head is not copied on every order from the moment it is raised.
Example 2 — an order that is rejected
Purchase Order APRL016/2026, raised four minutes after the first.
| Time | Who | Level | What they did | Log status |
|---|---|---|---|---|
| 20:29 | Priya Raman | Third | Raised the order | Created |
| 20:30 | Karthik Selvam | Second | Rejected it, with a memo | Rejected |
The chain stops there. Meena is never notified, because the order never reached her level. Priya gets the rejection with Karthik's memo and can correct and resubmit the order, which starts the chain again from her level.
Write the memo. It is the only thing that travels back to the person who raised it. A rejection with no memo produces a corrected order that has the same problem, and a second rejection.
What a resubmission looks like in the log
When a rejected order is corrected and sent back round, the log keeps both attempts. The new entries carry their own statuses, so the history reads as what it was rather than being overwritten:
| Log status | Means |
|---|---|
| Edit & Recreated | The same transaction was raised again after rejection. |
| Edited | The person who raised it changed it after submitting. |
| Edited & Approved | An approver corrected something small and approved in one step, rather than rejecting it over a typo. |
Example 3 — somebody outside the chain raises an order
A storekeeper whose designation group is not Purchase Buyer, Purchase Manager or Finance Head raises a purchase order.
| What happens | Why |
|---|---|
| No approval record is created | Their designation group matches none of the five levels, so there is no level to start the chain at. |
| The order proceeds normally | Nothing is holding it. |
This is the single most common surprise with the Approval app, and it is worth testing before you rely on a chain. Approval attaches to the designation group of the person raising the document. Anybody outside the configured groups bypasses it entirely — not as an override, but because there is nothing to attach to. If purchase orders must always be approved, every group that can raise one has to appear somewhere in the chain.
A sample approval log
This is the Approval tab of the completed order from Example 1, as the transaction carries it:
| User | Level | Status | Date | Memo |
|---|---|---|---|---|
| Priya Raman | Third | Created | 11 Oct 2026 20:25 | |
| Karthik Selvam | Second | Approved | 11 Oct 2026 20:30 | Prices checked against quote |
| Meena Sundar | Top | Approved | 11 Oct 2026 20:30 |
The log is read-only and travels with the transaction. A level shown as Super Admin rather than a named level is an action taken by a super-admin user outside the chain.
Worked setups for common situations
| You want | Fill in |
|---|---|
| One person signs off everything | Top only. The chain is one step. |
| A manager checks, finance finalises | Top = Finance, Second = the manager's group. |
| Buyer raises, manager checks, finance finalises | The three-level chain in these examples. |
| Nothing should be approved for a type right now | Tick Inactive on that type's rule rather than deleting it. |
Reading these examples against your own setup
- Check which transaction types have a rule at all — a type with no rule is never held.
- For each rule, note the lowest filled level. That is where documents enter the chain.
- Check that every designation group which raises that document appears somewhere in the chain, or those documents will bypass it (Example 3).
- Raise one test document and watch the log. It is the fastest way to confirm a chain does what you intended.
Related pages
- Approval Setup — entering the chain
- Approval Inquiry — the approver's screen
- Approval — what the app does
- Designation Group — the groups levels are assigned to