Every company that implements NetSuite builds approval workflows. Purchase orders over a threshold need a manager. Vendor bills need review before payment. Journal entries need a controller’s sign-off. The intent is sound: controls that live in the system instead of in people’s memories.
Then reality sets in. The approver is traveling and the warehouse can’t order parts. A rushed vendor payment gets entered by someone with an admin role to skip the queue. The approval chain has six steps for a $300 purchase and people start batching requests to avoid it. Within a year, the workflow that was meant to enforce control has become something everyone works around, which is worse than no workflow at all, because leadership believes a control exists when it doesn’t.
Approval workflows fail for design reasons, not technical ones. Here’s how to design ones that hold.
Start With the Control, Not the Workflow
Before building anything, be precise about what each approval is supposed to prevent. “Purchases need approval” isn’t a control. “No single person can commit the company to spend over $5,000 without a second person’s review” is.
Framing it that way exposes the design questions immediately. What counts as a commitment: the requisition, the purchase order, or the bill? Who is the appropriate second person for different categories and amounts? What happens when they’re unavailable? What’s the evidence that the control operated?
Approval workflows designed from a clear control statement tend to be simpler, because they only include the steps the control actually requires. Workflows designed from a vague sense that “things should be approved” grow steps nobody can justify.
The Workflows Most Companies Need
Purchase approvals
The most common and the most abused. The usual design is amount-based tiers: under a threshold, auto-approved or department manager; mid-range, department head; large, finance leadership or executive. Layer on category rules where they matter (capital expenditure, IT purchases, anything involving a new vendor).
The design mistake is making the tiers too fine or the thresholds too low. If 80% of purchase orders require two or more approvals, the workflow is a bottleneck and people will route around it. Set thresholds so that the routine majority flows quickly and the review effort concentrates on the spend that actually carries risk.
Vendor bill approvals
The control here is that bills are legitimate and match what was ordered and received. Three-way matching (PO, receipt, bill) handles most of this automatically when purchasing is run through the system properly. Approval workflows then only need to handle exceptions: bills without a PO, variances above tolerance, and bills from new vendors.
A common failure: routing every bill through manual approval even when a matched PO already exists. That’s double control with no added assurance and a lot of added friction.
Journal entry approvals
Manual journals are where financial misstatements most often hide, intentionally or not. The control is that no one can post a manual journal without a second review. NetSuite supports journal approval natively, and a workflow can add amount-based routing and segregation (the preparer cannot approve their own entry).
Keep it simple: one approver for most entries, a second for entries over a large threshold or touching sensitive accounts. Exempt system-generated journals, which already carry their own controls.
Sales-side approvals
Credit memos, customer refunds, discounts over a threshold, and orders that exceed credit limits. These protect against revenue leakage and are often forgotten in favor of the spend-side workflows.
Expense reports
Manager approval, with finance review above a threshold or for flagged policy exceptions. NetSuite’s native expense approval handles the basics; a workflow adds the routing and policy rules.
Design Principles That Keep Workflows Alive
Delegation and escalation are mandatory. Every approver needs a delegate, and every pending approval needs an escalation after a defined period. A workflow with no answer to “what if the approver is out” will be bypassed the first time they are.
Approval should be possible from email or mobile. Approvers who have to log into NetSuite to click a button approve things in batches, days late. Approval links in notifications, or a mobile-friendly approval list, change the behavior.
Rejection must carry a reason and return the record to the requester. Silent rejections create confusion and duplicate submissions.
Resubmission should restart approval appropriately. If a rejected PO is edited and resubmitted with a higher amount, it should re-route based on the new amount, not resume where it left off.
Editing an approved record should trigger re-approval when material fields change. Otherwise the control is defeated by approving a $1,000 PO and editing it to $10,000 afterward. Define which fields are material.
Keep the audit trail visible. Every approval and rejection, with who, when, and any comments, should be on the record. This is what auditors will ask for.
Report on it. A saved search of pending approvals by approver and age, reviewed weekly, catches bottlenecks before they become bypasses.
SuiteFlow or SuiteScript
Most approval workflows belong in SuiteFlow, NetSuite’s visual workflow builder. Amount tiers, role-based routing, state transitions, notifications, and approval buttons are all native to it. A good administrator can build, read, and adjust these, and the logic is visible.
Script becomes necessary when the routing logic exceeds what SuiteFlow handles cleanly: approval matrices driven by multiple dimensions (department, subsidiary, category, amount, vendor status) that would require dozens of workflow branches; dynamic approver lookup from a custom matrix record; integration with an external approval tool; or approval chains with complex parallel and conditional steps.
The common mistake is building a monster SuiteFlow with forty states to avoid scripting, which ends up less maintainable than a modest script with a configuration record behind it. A hybrid often works best: a custom record holding the approval matrix (editable by finance without a developer), a small script that determines approvers from it, and a simple workflow managing the states and notifications. That pattern is a staple of well-designed NetSuite customization, because it keeps the business logic editable while keeping the mechanics clean.
Testing and Rollout
Approval workflows touch everyone, so rollout matters. Test every path in sandbox, including delegation, escalation, rejection, resubmission, and edits after approval. Test with real roles, not administrator. Have actual approvers walk through the experience from their notification to their approval click.
Roll out with a clear announcement of thresholds, approvers, and expected turnaround times, and monitor the pending-approval report daily for the first month. Early bottlenecks are design feedback. Adjust quickly.
Maintaining It
Approval structures change. People leave, roles shift, thresholds that made sense at $10M in revenue are wrong at $50M. Workflows that aren’t maintained accumulate approvers who no longer work there and thresholds that no longer fit.
Review the approval design annually and whenever the organization restructures. Keep the matrix in a configuration record where finance can update it. And if the logic has grown complex enough that changes require a NetSuite developer, make sure that developer relationship is in place before the change is urgent.
The Measure of Success
A good approval workflow is one that people don’t notice. Routine requests flow in hours, exceptions get the scrutiny they deserve, approvers can act from their phone, and nobody has invented a workaround. The evidence it produces satisfies the auditors, and leadership can trust that the control they believe exists actually operates.
That outcome comes from designing around the control, keeping the steps minimal, planning for absences, and maintaining the thing after it’s live. None of it is technically difficult. All of it requires deciding what the workflow is for before deciding how it works.