Approval Workflows in SuiteFlow: A Complete Engineering Playbook

Quick summary: SuiteFlow is NetSuite’s point-and-click workflow engine, and it is the right tool for the overwhelming majority of approval processes — purchase orders, vendor bills, journal entries, expense reports, and custom records alike. An approval workflow is built from states (Pending Approval, Approved, Rejected), transitions that carry conditions, actions (Add Button, Send Email, Set Field Value, Lock Record), and triggers that decide when each one fires. This guide walks through how we design and ship production approval workflows: mapping the policy, architecting states and transitions, building amount-based routing, hardening with locking and notifications, and rolling out sandbox-first.

Over the last several years, our team has built approval workflows for ecommerce, wholesale, and B2B finance teams across the US, UK, CA, Australia, and New Zealand. The patterns below are the ones that survive a real month-end — not the textbook version that looks clean in a demo and falls apart the first time an approver is on leave.

Why use SuiteFlow for approvals?

Beyond “it’s built in and free,” the practical reasons compound quickly:

• No code for the common case — states, transitions, conditions, and actions express most approval policies without a single line of SuiteScript, so administrators and analysts can own them.
• Deterministic routing — a transaction follows the same path every time, removing the “someone forgot to route it” failure mode entirely.
• A real audit trail — the workflow execution log records every action, transition, and approver, which is exactly what auditors ask for.
• Native record integration — buttons, field updates, and locking happen on the record itself, so approvers never leave the transaction they’re reviewing. (See NetSuite’s SuiteFlow Overview.)
• A clean escalation point — when policy genuinely outgrows point-and-click, a Workflow Action Script slots in without rebuilding the workflow.

Step 1 — Map the approval policy before you draw anything

Before creating a single state, write the policy down as a table. We capture, for each record type:

• Record type and sub-type (e.g. Transaction → Purchase Order)
• The thresholds and who approves each band (under $5k auto-approve, $5k–$50k manager, over $50k CFO)
• How the approver is determined (supervisor hierarchy, a role, a Next Approver field, or a formula)
• What must be true to submit, and what should happen on reject (back to draft, or hard stop)
• Who gets notified, and whether the record should be locked while pending

If you can’t fill this table in, the workflow isn’t ready to build — you’re still negotiating policy, and you do not want to discover that mid-build.

Step 2 — Architect states and transitions

A SuiteFlow workflow is a set of states connected by transitions. A record sits in exactly one state at a time. Most approval workflows need three to six states; resist adding more than the policy actually requires.

[Initiation]            entry state — set Approval Status = Pending,
                        assign Next Approver, add "Submit" button
     │  (Submit clicked)
     ▼
[Pending Approval]      lock record, email approver, add Approve/Reject
     │            │
 (Approve)    (Reject)
     ▼            ▼
[Approved]     [Rejected]   set status, notify requester, unlock

The entry state is marked with the Start icon in the diagrammer and should do its setup work on the Before Record Load trigger so fields are stamped before anyone sees the form. Keep each state focused on one stage of the policy — a state that tries to be both “pending” and “approved” is a state you’ll be debugging at quarter-end. (Reference: Workflow States.)

Step 3 — Conditions and amount-based routing

A single Pending Approval state can hold several transitions, each with its own condition. NetSuite evaluates them in order and fires the first one whose condition is true, so order and mutual exclusivity are not optional — they are the design.

// Transition condition (formula) — route by amount
CASE
  WHEN {total} <= 5000  THEN 1   // skip straight to Approved
  WHEN {total} <= 50000 THEN 0   // hold for manager
  ELSE 0                          // hold for CFO
END = 1

"The moment you have three amount bands fighting over one state, stop and order the transitions deliberately. SuiteFlow takes the first true condition — design that order, don't inherit it by accident."

Two cautions. First, conditions can read field values, the current user’s role, saved-search results, or a formula — reach for the simplest one that expresses the rule, because a role check is far easier to audit than a nested formula. Second, when no approver exists (no supervisor, say), give the record an explicit auto-approve path; otherwise it parks in Pending forever. (Reference: Workflow Transitions.)

Step 4 — Actions, notifications, and locking

Actions are what the workflow does in a state. The four that carry almost every approval workflow are Add Button, Send Email, Set Field Value, and Lock Record:

• Add Button — place Approve and Reject buttons on the form, on the Before Record Load trigger, and wire each to a transition. A button with no transition vanishes on refresh.
• Send Email — notify the approver on entry to Pending Approval and the requester on Approved/Rejected, pulling record fields (amount, vendor, date) into the message.
• Set Field Value — stamp the Approval Status and an approval date so downstream logic and reporting can rely on it.
• Lock Record — on Before Record Load in the Pending state, remove edit access so the figures can’t change after submission.

The locking point is the one teams skip and regret. Without it, an approver can sign off a $4,000 order that was quietly edited up to $40,000 after routing — the control exists, but the integrity doesn’t. (Reference: Workflow Actions.)

Step 5 — Testing and rollout strategy

Never release an approval workflow straight to Production. Our standard approach has five phases:

1. Build in Testing status — set the workflow Release Status to Testing so it runs only for you while you wire states, transitions, and actions.
2. Walk every path in Sandbox — create test records at each amount band, and confirm every transition and action fires as designed, including the reject and resubmit paths.
3. Log in as each role — the requester, each approver, and an admin. Approval bugs almost always hide in role-specific permission and visibility differences.
4. Enable logging and read it — turn on workflow execution logging and verify the trigger order matches your intent before trusting it.
5. Release deliberately — switch Release Status to Released, and keep the previous definition handy so you can re-enable it if month-end surfaces something the sandbox didn’t.

Key takeaways

• Map the policy as a table first — most failed workflows are unfinished policy, not bad clicks.
• Keep states to the minimum the policy needs; one state, one stage.
• Order transitions deliberately — SuiteFlow fires the first true condition.
• Wire every Approve/Reject button to a transition, and lock the record while it’s pending.
• Build in Testing, validate across every role in Sandbox, then Release.

If you are staring at a manual approval process and not sure where to start, talk to one of our engineers — we will map your policy and give you a real workflow design, not a sales pitch. You can also browse our other NetSuite engineering articles for related deep-dives.

Frequently asked questions

Do I need SuiteScript to build an approval workflow in NetSuite?

No. SuiteFlow is NetSuite’s point-and-click workflow engine, and most approval processes — including multi-level and amount-based routing — can be built entirely with states, transitions, conditions, and actions, without writing any code. You only reach for a Workflow Action Script when the logic exceeds what conditions and formulas can express, such as dynamic approver lookups against a custom record or a callout to an external system.

Can SuiteFlow handle multi-level or amount-based approvals?

Yes. A single Pending Approval state can hold several transitions, each with its own condition. A common pattern routes amounts under a threshold straight to Approved, mid-range amounts to a manager, and high-value transactions to a director or CFO. NetSuite evaluates the transitions in order and fires the first one whose condition is true, so order and mutual exclusivity matter.

How long does it take to build an approval workflow in SuiteFlow?

A simple single-level approval on a standard transaction can be built and tested in a day. A tiered, multi-level approval with email notifications, record locking, escalation, and full sandbox validation across roles typically takes one to two weeks — most of it in mapping the policy and testing every path, not clicking the workflow together.

What is the difference between SuiteFlow and NetSuite's native approval routing?

NetSuite ships native approval routing for some record types (purchase orders, expense reports, requisitions) driven by the Approval Routing preference and the employee approval limit and supervisor hierarchy. SuiteFlow gives you full control when the native option is too rigid — custom states, conditions on any field, custom approver assignment, locking, and notifications. Many teams start with native routing and move to SuiteFlow when policy outgrows it.

Should I lock the record while it is pending approval?

Usually yes. Use the Lock Record action on the Before Record Load trigger in the Pending Approval state so the transaction can’t be edited after submission. Without it, an approver could approve a $4,000 order that the requester quietly bumped to $40,000 after routing. Locking keeps the approved figures honest and forces a re-submission if anything material changes.