How to Set Up Approval Routing in NetSuite

How to configure approval routing

1. 1For native routing, enable Setup > Company > Enable Features > Employees tab, check Purchase Approvals or Expense Report Approvals as needed.
2. 2Set each employee's approval authority on their employee record's Human Resources or Approval subtab: Purchase Approval Limit for POs, Approval Limit for expense reports.
3. 3Assign each employee a Supervisor on the employee record, since native routing sends transactions up the supervisor hierarchy until an approver with sufficient limit is found.
4. 4For anything beyond a straight hierarchy (parallel approvals, department-based routing, amount tiers spanning multiple approvers, conditional routing by subsidiary or class), build a SuiteFlow workflow instead under Customization > Workflow > Workflows > New.
5. 5In SuiteFlow, set the workflow's record type (Purchase Order, Vendor Bill, Expense Report, or any record), trigger (Before Record Submit or After Record Submit), and add states representing Pending Approval, Approved, Rejected.
6. 6Add Action items per state: Set Field Value to change the approval status field, Send Email for notifications, and transitions with conditions (e.g. total > 10000) that route to different next states or approver fields.
7. 7Use a Workflow Action Script (custom SuiteScript) inside the workflow when routing logic needs data not available to no-code conditions, such as looking up a department's approver from a custom setup record.
8. 8Test with Release Status set to Testing first, running transactions through every branch (approve, reject, escalate) before setting Release Status to Released.

Building a SuiteFlow approval workflow

// Workflow condition example: route to CFO above threshold
Condition: {custbody_total_amount} > 25000
Action: Set Field Value -> nextapprover = CFO employee record
Action: Send Email -> template: PO Escalation Notice

Notifications and escalation

Common pitfalls

• !Relying on native approval limits when routing actually needs department- or subsidiary-based logic, then discovering the supervisor hierarchy does not match the real approval matrix.
• !Forgetting to set Purchase Approval Limit or Approval Limit on every employee in the chain, which silently blocks escalation at whichever level has no limit set.
• !Building a SuiteFlow approval workflow without a Rejected state and a clear way to return the record to the requester, leaving rejected transactions in limbo.
• !Not testing parallel or multi-branch approval paths before release, so an edge case (e.g. a $0 PO, or a PO with no assigned department) falls through with no valid transition.
• !Hardcoding an approver's internal ID in a workflow condition instead of looking it up dynamically, breaking routing the moment that employee record is deactivated or replaced.
• !Mixing native approval fields and a custom SuiteFlow approval status field on the same record type, causing two approval mechanisms to conflict.