How to Build an Approval Workflow in NetSuite SuiteFlow

How do states work in a SuiteFlow approval workflow?

States are the stages a record can be in. A basic approval workflow has four:

• Draft: the initial state, where the record is being prepared
• Pending Approval: the record has been submitted and is waiting for a decision
• Approved: the approver has accepted the record
• Rejected: the approver has declined the record

One state is designated as the initial state, the state every new record enters automatically. For an approval workflow, this is Draft. The workflow engine tracks which state each record is in and makes that state visible in a workflow status field on the record form.

Each state can also have entry and exit actions: things that happen when a record arrives in or leaves a state. A common entry action on Pending Approval is to send an email to the approver. A common exit action on Approved is to set a status field on the record.

How do transitions and approval buttons work?

Transitions define how records move between states. Each transition has:

• A source state (where the record is coming from)
• A destination state (where it goes)
• A trigger (what causes the transition to fire)
• Optional entry criteria (conditions that must be true for the transition to be available)
• Optional actions (what happens when the transition fires)

For approval workflows, the most common trigger is a button on the record form. SuiteFlow adds custom buttons to the record form for each transition that has button-based triggering enabled. The button only appears to users who meet the transition's role or condition requirements.

To restrict the Approve and Reject buttons to approvers only, set the transition's role restriction to the role that should have approval authority. The submitter sees the Submit button (transitioning from Draft to Pending Approval) but cannot see the Approve or Reject buttons. The approver sees Approve and Reject but not Submit.

What actions should fire on each transition?

Submit transition (Draft to Pending Approval):

• Set a field on the record to record who submitted it and when
• Send an email to the approver notifying them that a record is waiting for their decision
• Optionally lock certain fields so the record cannot be edited while pending

Approve transition (Pending Approval to Approved):

• Set the record's approval status field to Approved
• Send an email to the submitter confirming the approval
• Optionally trigger downstream actions (unlock the record, create a related record)

Reject transition (Pending Approval to Rejected):

• Set a field to record the rejection reason (you can add a text field to capture this)
• Send an email to the submitter with the rejection notification
• The email should explain next steps: correct and resubmit, or escalate

All of these are handled through workflow actions configured on each transition. NetSuite's email action can use saved email templates, so the notifications can be formatted consistently without requiring manual composition.

How do you restrict which records enter the workflow?

By default, a SuiteFlow workflow fires on every record of the target type that is created or edited. For an approval workflow, you typically only want it to fire for records above a certain threshold or of a specific type.

Entry criteria are conditions set on the workflow itself or on individual states and transitions. Common examples:

• Amount exceeds a threshold: only trigger for records where the total amount is above a certain value
• Record type filter: for multi-purpose record types, filter by a category or type field
• Subsidiary: only apply the workflow to records in specific subsidiaries

Entry criteria use the same filter conditions as saved searches. You can combine multiple conditions with AND/OR logic and reference any field on the record or its related records.

What workflow context settings prevent common mistakes?

The workflow context controls when the workflow's logic runs relative to the record save. The most common mistakes come from wrong context settings.

Event-based workflows fire when something specific happens to the record: when it is created, when it is edited, or when a specific field changes. An approval workflow should typically fire when a record is first created (to put it in the Draft state) and when transitions are triggered (by button click).

Trigger on: set to "Before Record Submit" for actions that need to run before the record is saved (like field validation or setting a required field). Set to "After Record Submit" for actions that depend on the record being committed (like sending an email that references the record ID).

Context restrictions: if the workflow should only fire when a user saves from the UI (not during CSV import or API saves), add a context restriction for "User Interface" only. Without this, the workflow fires on every save path, which can create unexpected state transitions during bulk imports.

How do multi-level approvals work?

For two-level approvals (manager then finance team, for example), extend the state machine with additional states:

• Draft
• Pending Manager Approval
• Pending Finance Approval
• Approved
• Rejected

The Approve transition from Pending Manager Approval moves the record to Pending Finance Approval, not directly to Approved. The Finance Approve transition then moves it to the final Approved state. Each level has its own role-restricted buttons and its own email notifications.

The pattern scales to as many levels as needed, but workflows with more than three approval stages are harder to audit and maintain. If the approval logic is genuinely complex (dynamic approvers based on record data, parallel approvals, conditional routing), that logic is better handled in a SuiteScript Workflow Action Script rather than through SuiteFlow's native condition builder.

---

If you need help designing or building a workflow that goes beyond the standard state machine (dynamic approver lookup, parallel branches, cross-record updates), our workflow automation service covers both SuiteFlow design and Workflow Action Script development. For related reading, see NetSuite Workflow vs SuiteScript: Which to Use and When and 5 Common Workflow Automation Mistakes.

Frequently asked questions

Q: What is the difference between SuiteFlow and NetSuite's built-in approval routing? A: NetSuite has native approval routing for specific record types like Purchase Orders and Expense Reports, configured under Setup rather than through SuiteFlow. The built-in routing supports supervisor hierarchies and amount thresholds without custom workflow setup. SuiteFlow is more flexible and works on any record type, including custom records and record types that don't have native approval support. The two can coexist on the same record type.

Q: Can the approval email include a link directly to the record? A: Yes. NetSuite email templates support field references, and the workflow can pass the record's internal ID and type into the template. NetSuite generates a direct URL to the record that the approver can click to open it immediately. The link uses the approver's account URL and record type.

Q: How do you prevent the workflow from firing on CSV imports? A: Add a context restriction to the workflow or to specific transitions. Set the execution context to User Interface to prevent the workflow from triggering during CSV imports, API saves, and saves from other scripts. Without this restriction, submitting a CSV import of 500 records will attempt to put all 500 into Pending Approval simultaneously.

Q: Can a workflow send different emails based on who is approving? A: Yes. Workflow email actions can use formula-based recipient fields that reference the record or related records. If the approver is stored on the record as a field (set dynamically by a script or by the submitter), the email action can address the notification to that field's value rather than a static role or email address.

Q: What happens to a pending record if the workflow is deactivated? A: Deactivating a workflow stops it from processing new transitions, but records already in a workflow state retain that state. They remain stuck in Pending Approval until the workflow is re-activated or manually updated. Before deactivating an active approval workflow, resolve all open records or document the manual steps needed to process them without the workflow.