A purchase request approval workflow should leave the buyer with a clear answer: what has been approved, for how much, and on what basis? In Folderit, you can collect the request in an eForm, route it through an amount-based approval process, then use a linked form to copy selected details into a purchase-order record.
The buyer starts that last step from the approved request. They review the copied values, complete the order details and submit the new form. That gives you two connected records with different jobs: one explains the purchase decision; the other holds the order being prepared.
Here is a practical setup for a team buying one item or service per request. The EUR amounts and approval limit are illustrative. Adapt them to your purchasing policy.
Keep the request and the order separate
A requester may know that the warehouse needs a replacement printer, but not the final delivery charge or supplier terms. Approving that need is a different decision from releasing an order with a confirmed price.
Set up two templates under Admin tools → Form templates: Purchase request and Purchase order. Start with the eForms guide if you have not created a template before.
For this example, the requester enters the specification and estimate, a designated budget owner reviews the request, and a buyer completes the order. Choose actual workflow recipients for the team. A field labelled Budget owner does not, by itself, configure routing to that person.
Choose the fields that should carry into the order
Use the following field map as a starting point. Make the request’s description, quantity, estimate, currency and cost centre required. Add a required business reason so an approver can assess the need without chasing an explanation.
| Purchase request field | Field type | Purchase order destination |
|---|---|---|
| Item or service | Text | Item description |
| Quantity | Number | Quantity |
| Estimated total cost | Number | Request estimate |
| Currency | Select | Currency |
| Cost centre | Select | Cost centre |
| Required by | Date | Requested delivery date |
| Delivery location | Text | Delivery location |
| Business reason | Textarea | Internal justification, if useful to the buyer |
On the request, also add a Requester field and a File field for a supporting quote. On the order, add Supplier, Buyer, Confirmed order value and Confirmed delivery date. Keep Request estimate separate from Confirmed order value: overwriting the estimate would hide a price change.
Define what the estimate includes, such as delivery and applicable taxes, so reviewers compare like with like. The Number fields in this recipe hold entered values; a person checks the arithmetic. Table fields are available for multiple lines, but line-item mapping, totals and document layout need their own design and checks.
For a useful completeness check, Yale’s requisition guidance lists details such as quantity, specifications, delivery location and charging instructions. Those are examples from Yale’s process, not requirements imposed by Folderit.
Build the purchase request approval workflow
Create a folder for incoming requests. In Workflow Designer, configure an Item created starting point restricted to the Purchase request form type and the intended location. Set the folder scope deliberately, including subfolders only when their requests belong in this process.
For a EUR-only route, require Currency equal to EUR and a positive Estimated total cost before the amount decision. Decide how staff will correct incomplete or unsupported entries. A record excluded by the starting conditions has not entered the approval process, so someone must watch for those exceptions.
Suppose your policy requires the budget owner’s approval for every request, plus a director’s approval when the estimate is above EUR 5,000. Add a Condition step for Estimated total cost greater than 5000. Its true path leads to the budget-owner and director approvals in sequence; its false path leads to the budget-owner approval alone.
| Example entry | Intended handling |
|---|---|
| EUR 4,999.99 | Budget owner approval |
| EUR 5,000.00 | Budget owner approval |
| EUR 5,000.01 | Budget owner, then director approval |
| Missing amount, zero or another currency | Correct the record or handle it through a separately defined process |
The equality case deserves its own test. If your policy says “EUR 5,000 and above,” configure that boundary instead. The condition compares one entered amount with a threshold; it neither converts currencies nor checks the department’s remaining budget across other purchases.
In a Condition step, the red Failure output means the condition is false. In an approval action, a failure can represent an unsuccessful decision. Give those paths different destinations so a lower-value request is not treated as a rejected one.
Make approval outcomes useful to the buyer
Tell reviewers what their decision covers: the item, quantity, estimate, quote and cost centre. Add a Request action step for each approval stage, select the Approval method and enable show data fields. Require All recipients must complete and explicitly set the failure threshold to Reject count: 1 so a rejection stops that stage. On the higher route, connect the budget-owner step’s Success output to a separate director approval step with the same completion and rejection settings.
After the final required approval, a Move step can send the request to an Approved requests folder. Route rejection to a correction process and assign responsibility for resubmission. Handle a timeout as overdue work needing attention. It should never silently become approval. Configure the separate Timeout setting for that route; the Due By deadline is informational.
Folderit’s approval workflow guide explains the available review arrangements. Check the recorded decision when preparing an order; a folder name or manually entered Status value is not a substitute for that decision.
Configure the linked purchase-order form
- Open Admin tools → Form templates.
- In the Purchase request template’s Actions column, open the gear menu and select Add linked form.
- Select Purchase order as the destination template.
- Set Button text to Create Purchase Order.
- Pair each source field with its destination from the field map. Leave Do not copy for values that should stay on the request.
- Review the pairs and save.
The two fields do not need identical names. Folderit’s linked forms instructions use this request-to-order example to explain how selected values carry into a new form.
The buyer opens the approved request, checks the decision and selects Create Purchase Order. After reviewing the copied values, they complete the supplier, confirmed price and delivery details, then submit. Folderit connects the source and new record under Related items. Check the new record’s location and move it if your order records belong in a separate folder.
Plan permissions and the buyer’s procedure explicitly. The linked-form button is a record-creation action; the documentation does not establish that it becomes available only after approval. Creating an order record must not be mistaken for permission to issue it.
Check numbering and price changes before release
Agree the order reference before rollout. Linked forms can give a new record a reply-style suffix when the source has a Document number and the destination number is left empty. That inherited number can take precedence over the destination template’s automatic numbering. Test the result against your purchase-order numbering convention rather than assuming every linked order will receive a separate PO sequence.
Now try a fictional purchase: four chairs are approved at a total estimate of EUR 1,200. The supplier’s final total is EUR 1,280 including delivery. Keep both values visible and apply your policy for the extra EUR 80 before sending the order. A copied estimate does not decide whether the change is acceptable. A supplier, quantity or specification change may also need another review.
If the buyer needs a PDF or DOCX, configure an ODT template for the Purchase order form through document generation. Include the confirmed order details in the supplier-facing output; leave internal justification out unless it belongs there. Preview the generated file before release.
Submitting a form creates a record. Sending the order, reserving funds and creating an accounting entry are separate actions. Assign the release step to a person or a separately verified integration, and retain evidence of what was actually sent.
Run a small test before inviting the team
Use fictional records to check the whole handoff:
- Submit the three EUR boundary amounts above and verify the recipients and sequence.
- Reject a request and let another reach its timeout. Confirm that neither reaches the approved route.
- Submit a non-EUR request and a record outside the intended folder scope. Check how excluded work is noticed.
- Create one linked order and compare every copied value, its number, location and Related items link.
- Change the final price and confirm who gives any additional approval.
- Sign in with ordinary requester and buyer roles to check what each can see, create and edit.
Start with one team’s requests and one clearly defined approval policy. Once the handoff works reliably, extend it to other cost centres. When the supplier invoice arrives, use your invoice approval process to check the invoice and supporting evidence. The original request, issued order and invoice decision each answer a different question.
