Implementation Guide

How to Build an Approval Workflow in NetSuite SuiteFlow

A practical, step-by-step guide that turns the playbook into a real workflow — map the policy, create the workflow and trigger, lay out the states, add amount-based routing, wire the buttons and notifications, then roll out safely — with links to the official NetSuite documentation so you can verify everything for yourself.

Practical developer guide · Backed by the official NetSuite Help Center

Chief Technology Officer · 3x NetSuite Certified
Updated 8 min read
Back to the main article

This is the practical companion to our Approval Workflows in SuiteFlow guide. The main article explains why SuiteFlow is the right tool and how states, transitions, conditions, and actions fit together; this page is the plain checklist for actually building one. Work through the steps in order — map the policy first, roll out sandbox-first — and use the official NetSuite documentation link under every step to confirm the exact setting as you go.

Before you start — prerequisites

  • A sandbox: build and validate the whole workflow in a Sandbox or Release Preview account first — never in Production.
  • The SuiteFlow feature on: confirm SuiteFlow (Workflow) is enabled under Enable Features, and your role has the Workflow permission.
  • A written policy: have the approval thresholds, approvers, and notification rules agreed before you start clicking.

What you'll set up

  1. Map your approval policy
  2. Create the workflow and set its trigger
  3. Lay out the states
  4. Add transitions, conditions and routing
  5. Configure actions: buttons, emails, fields, locking
  6. Stamp status and confirm the audit trail
  7. Test in Sandbox and release
1

Map your approval policy

You can’t build a workflow you haven’t agreed. Write the policy down as a table before you create a single state — most failed workflows are unfinished policy, not bad clicks.

Plan:  record type → thresholds → approvers → notify & lock rules
  1. List each record type and sub-type in scope (e.g. Transaction → Purchase Order) and the amount bands that route differently.
  2. Decide how each approver is determined — supervisor hierarchy, a specific role, a Next Approver field, or a formula.
  3. Decide what happens on reject, who gets notified, and whether the record is locked while pending.
NetSuite docs SuiteFlow Overview Customize with Workflows
2

Create the workflow and set its trigger

Create the workflow on the target record and decide when it should run. The trigger you choose determines whether the approval starts on create, on edit, or on submit.

Go to:  Customization > Workflow > Workflows > New
  1. Set the Record Type and Sub Type, and set Release Status to Testing so it runs only for you while you build.
  2. Choose the initiation trigger — Event Based (On Create / On Update) or a Before/After Submit trigger — to match your policy.
  3. Understand the trigger execution order so your setup runs before approvers see the form, not after.
NetSuite docs Workflow Triggers Trigger Execution Model
3

Lay out the states

States are the stages a record passes through, and it sits in exactly one at a time. Keep them to the minimum the policy needs — one state, one stage.

Build:  Initiation → Pending Approval → Approved / Rejected
  1. Add an entry Initiation state that stamps the approval status to Pending and assigns the approver.
  2. Add a Pending Approval state where the record waits for a decision.
  3. Add terminal Approved and Rejected states for the two outcomes.
NetSuite docs Workflow States SuiteFlow Overview
4

Add transitions, conditions and routing

Transitions are the arrows between states. Each can carry a condition — this is where amount-based routing lives. NetSuite fires the first transition whose condition is true, so order matters.

Code:  conditions ordered: ≤$5k auto → ≤$50k manager → >$50k CFO
  1. Draw a transition out of Pending Approval for each outcome and approval band.
  2. Add a condition to each transition (by amount, role, department, or a formula) and order them so they are mutually exclusive.
  3. Add an explicit auto-approve path for cases where no approver exists, so records never park in Pending forever.
NetSuite docs Workflow Transitions Requisition Approval Example
5

Configure actions: buttons, emails, fields, locking

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

Code:  Add Button + Send Email + Set Field Value + Lock Record
  1. Add Approve and Reject buttons on the Before Record Load trigger and wire each to a transition — a button with no transition vanishes on refresh.
  2. Add Send Email to notify the approver on entry to Pending and the requester on the outcome.
  3. Add Lock Record on Before Record Load in Pending so figures can’t change after submission.
NetSuite docs Workflow Actions Workflow Actions Overview
6

Stamp status and confirm the audit trail

The audit trail is half the reason you’re automating. Stamp the outcome on the record and confirm every action and transition is being logged.

Code:  Set Field Value (status + date) & enable execution logging
  1. Use Set Field Value in the Approved/Rejected states to stamp the Approval Status and an approval date for reporting.
  2. Notify the requester of the outcome so the loop closes without a chase email.
  3. Turn on workflow execution logging and confirm the history records who approved what, when, and at which amount.
NetSuite docs Workflow Actions Overview FAQ: SuiteFlow
7

Test in Sandbox and release

Rollout risk is the real risk. Prove every path and every role in Sandbox, read the execution log, then promote deliberately.

Process:  Testing → validate every band & role → Released
  1. Create test records at each amount band and confirm every transition and action fires — including reject and resubmit.
  2. Log in as the requester, each approver, and an admin; approval bugs hide in role-specific permissions.
  3. Set Release Status to Released, and keep the previous definition handy as a rollback.
NetSuite docs SuiteFlow Reference & Examples SuiteFlow Overview

A note on accuracy: NetSuite menu paths, action names, and trigger options evolve between releases, and some behaviors differ by edition (for example, native approval routing availability and which records support it). Always confirm each setting against its official reference, and test the workflow in Sandbox before setting it to Released in Production.

Official NetSuite documentation

Every step links to the source. Full help center: NetSuite Applications Suite — Online Help.

Where point-and-click ends and engineering begins

Everything above builds a complete approval workflow with no code at all. What sits beyond point-and-click — dynamic approver lookups against a custom record, validation that spans several transactions, escalation timers, or a callout to an external system — is where a Workflow Action Script earns its place. The pattern stays the same: keep the policy in SuiteFlow and push the protocol detail into a small, tested script.

An approval workflow touches live financial controls, so build it in a Sandbox, walk every amount band and role, and confirm the audit trail before you set it to Released. For the full reasoning behind each decision — the state model, amount-based routing, and the locking strategy — read the companion guide.

Back to the main article
Building an approval workflow? Our NetSuite engineers map your approval policy, build it in SuiteFlow with proper routing, notifications, and record locking, and roll out Sandbox-first — so nothing breaks at month-end.
Talk to a NetSuite workflow engineer

Documentation links point to the official Oracle NetSuite Help Center (docs.oracle.com). Exact menu paths and feature names vary by NetSuite version and edition — confirm each step against the linked Help Center page and validate in Sandbox first.