The purchase order approval process is one of the most manual workflows in manufacturing operations. A purchase requisition gets submitted by email or on paper. A purchasing coordinator manually routes it to the right approver. The approver responds by email. The coordinator creates the PO in the ERP. The PO gets emailed to the supplier.
Every step in that sequence is manual. Every step can be automated. This tutorial builds the full PO approval workflow in n8n, from the initial requisition form to the PO created directly in the ERP via API.
An n8n workflow that:
n8n instance running version 1.0 or later.
ERP with a REST API. This tutorial uses the ERP API for PO creation in Step 6. ERPs with documented REST APIs for PO creation: NetSuite (REST Record API), SAP Business One (Service Layer), Epicor Kinetic (REST API), and JobBOSS2. If your ERP does not have a REST API, the PO creation step can be replaced with an email to the purchasing team containing the approved requisition details formatted as a PO.
ERP API credentials configured in n8n. Add an HTTP Request node credential with your ERP's base URL and authentication (API key or OAuth2 depending on your ERP). Test the connection by making a read request (GET a list of existing POs) before building the write step.
Email or Slack for approver notifications.
Defined approval matrix. Document before building: who approves what amounts, what the escalation path is, and what happens when a requisition is rejected. The Switch node routing reflects these rules directly.
n8n Form Trigger (requisition submission)
→ Set node (normalize form data)
→ Switch node (route by amount)
→ Branch A: Under $500, auto-approve, skip to PO creation
→ Branch B: $500 to $2,000, route to department manager
→ Branch C: Over $2,000, route to COO or VP Operations
→ Gmail or Slack (send approval request with approve/reject links)
→ Wait node (hold up to 24 hours)
→ IF node (approved or rejected)
→ Approved: HTTP Request to ERP (create PO), notify requester
→ Rejected: Notify requester with reason
→ Schedule sub-workflow: escalate if no response in 24 hours
Add an n8n Form Trigger node as the starting point. Configure the form with these fields:
Click the form URL to preview it and confirm all fields render correctly. This is the form your team will use to submit purchase requests.
Add a Set node to extract and rename the form fields into clean variable names. This makes the downstream expressions easier to read and maintain.
Key fields to set:
Add a Switch node and configure three output branches based on the amount field:
For urgency-based overrides (Expedited requests under $500 that still require a check), add a fourth branch or add an AND condition to Branch A: auto-approve only if urgency is Standard. Expedited requests route to the manager regardless of amount.
For Branches B and C, add a Gmail node to send the approval request. The email should include:
Keep the email format clean. Approvers who receive too much context in the approval email start ignoring them. The essentials are the item, vendor, amount, requester, and the two action buttons.
For Slack-based approvals, use a Slack node with Block Kit formatting to create an inline approve/reject button. The button actions trigger separate webhook URLs in n8n.
Add a Wait node after the Gmail send. Configure it to resume on webhook call with a 24-hour limit.
The Wait node pauses the workflow here. Nothing progresses until the approver clicks a link or the 24 hours expire.
For the dual callback approach (separate workflows for approved and rejected): the email links point to two different webhook-triggered workflows. The main workflow ends after sending the approval email and logging the pending status. The callback workflows handle the resolution.
In the approved workflow (triggered when the approver clicks Approve), add an HTTP Request node to create the PO in the ERP.
The API call structure varies by ERP. For NetSuite as an example:
For SAP Business One, the Service Layer endpoint for PO creation is: POST /b1s/v1/PurchaseOrders
Map the requisition data fields to the ERP's required fields. Test this step in isolation using a test purchase order before connecting it to the live approval flow.
If the ERP API call fails, add an error handler to notify the purchasing team so they can create the PO manually. Do not let failures silently drop.
After the PO is created successfully:
On the rejection path, send the requester a clear notification with the rejection reason and instructions to revise and resubmit if applicable.
ERP API authentication setup. ERP APIs typically require OAuth, token-based auth, or session-based authentication that expires. Test your credentials carefully and note the token refresh requirements. NetSuite tokens do not expire but require a specific HMAC-SHA256 signing process. SAP B1 sessions expire and need a login call before each API interaction.
Vendor record must exist in the ERP before PO creation. If the vendor is new, the PO creation call will fail because the vendor record does not yet exist. Add a vendor lookup step before the HTTP Request node: GET the vendor by name. If not found, route to the vendor onboarding sub-workflow or flag to purchasing before creating the PO.
Amount field type. n8n Form Trigger returns form fields as strings. Ensure the amount is parsed as a number (Number($json.amount)) before the Switch node comparison. String comparison of "1500" greater than 500 may behave unexpectedly depending on how the Switch node handles type coercion.
The PO approval workflow is the upstream half of the procurement automation. Once a PO is created via API, the next automation layer monitors supplier acknowledgment: did the supplier confirm receipt of the PO within 48 hours? If not, n8n sends an automated follow-up.
That workflow, combined with inbound shipment tracking, builds the full purchase-to-pay visibility loop covered in the Week 2 supply chain post.
The Flow Kaizen guide includes the ERP API prerequisite checklist, covering what credentials you need, how to test API access before scoping the build, and which ERP modules need to be enabled for PO creation via API.