Purchase / Expense Approval
Install the Purchase Approval pack, create a request, and walk it through Request → Manager Approval → Finance Review → Fulfilment on the Kanban board — then send it back the two ways real approvals loop back.
Real approval processes don't run in a straight line. A manager rejects a request and it goes back to the requester. A purchase is fulfilled, then someone spots an error and it has to be re-opened. The Purchase / Expense Approval pack models that — a purchase request moving through Request → Manager Approval → Finance Review → Fulfilment — and shows the two ways a process loops back, plus how Scrydon redoes only the work that actually depends on what changed.
What it models
| Stage | Who acts | What happens |
|---|---|---|
| Request | Requester | Submit the request: line items, estimated cost, business justification, cost-centre code, and an optional quote. |
| Manager Approval | Line Manager | Review and Approve to move forward — or Reject, which sends the request straight back to the requester to revise. |
| Finance Review | Finance | Check budget and policy. Onboarding a new supplier happens here too, in parallel — it doesn't hold up the approval. |
| Fulfilment | Procurement | Raise the purchase order, confirm delivery, close the request. A fulfilled request can still be re-opened if something needs fixing. |
The request opens on the Kanban board: each stage is a column, the request's tasks are cards that move left-to-right as it progresses — and, when it loops back, right-to-left.
Set it up
Install the pack (IT admin)
In the platform admin area, go to Settings → Platform → Packs. Either:
- click Upload pack and choose the file you downloaded, then Install — a one-off install; or
- add it under Sources if you want the platform to keep it in sync from a pack source.
Installing brings in the pack's data model and the Purchase / Expense Approval process-flow template, ready for your workspaces to use.
Add it from the Marketplace
Open the Marketplace. Find the Purchase / Expense Approval template and add it to your workspace. (The Marketplace is where installed process-flow templates become available to workspace teams.)
Create a request
Go to Process Flows and create a new flow from the Purchase / Expense Approval template — name it something like Office laptops — Q3 refresh. It opens on the Kanban board by default, with the four stages as columns. Optionally assign the Requester / Line Manager / Finance / Procurement roles to real users; otherwise anyone with access can act on the cards.
Test the loopback
Move the request forward first: complete the Request tasks so the card lands in Manager Approval. Now try the two ways it goes back.
1. Reject sends it back to the requester
This is the everyday rework loop. In Manager Approval, open the approval and click Reject — add a comment like "Cost exceeds the single-approver limit, please split into two requests."
The request immediately returns to the Request column — not forward. The requester revises and resubmits, and it comes back to Manager Approval for another look. Nothing is lost: the activity history of the first submission stays on the request, so the manager can see what changed between rounds.
The pack author wired this with a single setting on the approval — there's no per-instance configuration. Finance Review works the same way, so Finance can also bounce a request back if it finds a coding error.
2. Re-open a fulfilled request
Sometimes a request is already fulfilled and you still need to change it. Drive the request all the way to Fulfilment, then on the Kanban board drag its card back to an earlier column — or use the card's Send back to… menu. For this pack the menu only offers Request and Manager Approval (the author restricted where a fulfilled request may return).
3. See exactly what gets redone — and what's kept
Before the send-back is committed, a confirmation dialog tells you the blast radius. Sending a fulfilled request back to Request shows something like:
| Task | After re-open |
|---|---|
| Submit request | Re-opened — this is where you're sending it |
| Manager approval | Re-opened — it depends on the request |
| Finance review | Re-opened — it depends on the approval |
| Issue purchase order | Re-opened — it depends on finance review |
| Register supplier | Preserved — it doesn't depend on the request details |
The point: Scrydon re-opens the approval chain (everything that was built on the request you're changing) but keeps the supplier-onboarding work, because that didn't depend on what changed. Confirm the dialog and you'll see the re-opened cards flagged as re-opened on the board, with their earlier history intact.
You get this same "what will change?" preview whether the loop is triggered by a manager's rejection or by a manual send-back — so no one re-does work by surprise.