In this post, we’re going to look at adding workflows to a NetSuite instance for the purposes of customizing a web store. We’re going to cover:

  • What workflows are
  • When they are a good fit as a customization tool (and when they are not)
  • The basics of a workflow
  • How to add a workflow, including an example scenario
  • Tips and tricks

As always, if you’re interested in implementing something in a blog post, I recommend reading the documentation first.

Introduction to Workflows

When it comes to customizing your NetSuite instance, there are a number of tools available to you through SuiteCloud. You should also be familiar with SuiteScript, which is our core business process automation tool. It can be used for a number of different purposes as it enables full-featured application-level scripting capabilities. It can be used to facilitate sophisticated customizations to handle procedural logic on both the client and server sides, and also provides features such as robust debugging.

If you’re not a developer, however, then not knowing the language can make it difficult to implement the customizations you want, or make modifications to existing ones. This is where SuiteFlow can come in.

SuiteFlow enables business users to implement a subset of the use cases you can achieve with SuiteScript without knowing how to code. The different maker is that SuiteFlow is a point-and-click interface, and therefore no scripting is needed. It does not do everything that SuiteScript can do — it’s not intended too — but it can be very powerful.

SuiteFlow creates workflows, which, in terms of NetSuite, are an automated business process that manipulates standard or custom records. At its core, you use the user interface to define a number of stages and then conditional actions that manipulate the record based on your set criteria.

When Workflows are a Good Fit

While we’re going to talk up the benefits of SuiteFlow in this post, it’s good to make clear that workflows are not always the best tool for the job. Here are some of the positives first.


When deciding how to implement your desired customization, you should take time to go over the requirements and first see if it’s a relatively simple business process. For example, if the business case is to modify a custom record or trigger an email when a first record is modified, then it sounds like a workflow would be a good fit. If you need to do a lot of calculations or perform complex conditional logic, then consider alternative customization paths.

Easy to Build and Maintain

A key benefit I already mentioned is that customization can effectively be completed entirely through configuration changes. If you are a developer, this can be a boon because it means that you can show your business users this tool and let them get on with it themselves. Alternatively, it means that you can create the initial workflow for them, and then leave them to make changes to it themselves. In other words, if you or your business user is concerned about ongoing maintenance of the customization, then a workflow can be a great tool.

An important thing to keep in mind about this, though, is that while no scripting knowledge is required, the user is required to understand logic concepts (eg parentheses, operators, etc) saved searches and business mapping. So, make sure you and they brush up!

Example Use Cases

If you think that a workflow will be a good fit, let’s compare your idea against some of the examples we can think of.

Broadly speaking, we think there are four broad areas we recommend workflows for:

Approval Management
  • Sales orders
  • Estimates/quotes
Record Transformation
  • Quote to sales order
Field Data Modification
  • Mandatory/non-mandatory
  • Set field value
  • Hide/unhide fields
Activity Scheduling
  • Marketing messages
  • Conditional/mass update of records
  • Automatic notifications (ie, email employees)

I hope that from this list you can get a sense of the sort of customizations we are talking about here. All of them meet the criteria of a reasonably simple trigger/action mechanism; ie, “this thing has happened, so do that action”.

So, when is scripting (or another customization method) a better fit? Consider SuiteScript if you need:

  • More power, flexibility or application coverage
  • To perform complex logic or calculations
  • To process large volumes of data, especially for actions that could be done with map/reduce (workflows only have one queue)

Workflow Basics

Before we get to creating an example workflow, we need to understand the basics of what we’re dealing with.


Firstly, you need to enable the feature. Go to Setup > Company > Enable Features > SuiteCloud and enable SuiteFlow.

This triggers some prompts asking you to enable client scripts and SuiteScript, if they are not already enabled. This is what enables the behind-the-scenes magic.

You’ll also need to make sure that any user that wants to set up or modify the workflow has the right permission attached to their role. To do this, edit the role and make sure the Setup > Workflow permission is added.

To add a new workflow, go to Customization > Workflow > Workflows > New.

Since 2015.1, NetSuite has provided workflow templates to help you get started with common scenarios, such as sales order and purchase order approvals. Instead of working from a clean slate, you can choose a template that most closely reflects your business needs and go from there.

Elements of a Workflow

There are many different parts to a workflow and the best way to present them is in a table:

Base record​The primary record type affected by the workflow​
States​The stages or statuses of the record within the business process​
Triggers​Events that occur during the process that starts the workflow​
Actions​Tasks that are going to be performed once triggered​
Transitions​States to move the record to​
Conditions​Requirements that must be met for the workflow to initiate, or for an action/transition to run​
Custom fields​Variables that you can use in workflows, actions, and transitions​
Revisions​A list of changes made to the workflow or its children​

With that all in mind, let’s move on to an example!

Example Workflow: Order Quote Approval

In this scenario, we’re assuming that the business we are building the workflow for has a business requirement that requires automating. They’ve listed their requirements as follows:

When a customer submits an order quote through the web store with a total higher than $3000, it must be escalated to a sales rep’s supervisor, who can then approve or reject the quote​. The sales rep must be then be notified.

I emphasized the important parts — can you see, using the elements described above, how we might map the business requirements to the NetSuite functionality? Let’s take a look.

Step 1: Define Basic Workflow Information

When you create a new workflow (not from a template), you’re first shown a section to define basic information.

For our example, we’re going to set it up as follows:

  • Record Type — Transaction
  • Sub Type — Estimate
  • Execute as Admin — (checked)
  • Release Status — Testing

You can the name and ID as you wish, if you’re following along.

An important thing is that we have checked Execute as Admin because we need to grant access to records that the workflow will not usually have access to (employee records).

Another is that once you set the record type and save the workflow, you cannot change this later — make sure you get it right!

Step 2: Define Workflow Initiation

Below the basic information are two radio buttons that you use to specify how the workflow should be started. Event based workflows start when a particular thing happens; scheduled ones run at a particular time and frequency.

For our workflow, we are creating an event based one.

When this is selected, you can define what the event is the section below the radio buttons.

In this example, we’re going to define it as:

  • On Create — (checked)
  • Contexts — Web Store
  • Use — Visual Builder
  • Condition — Total >= 3000.00

To set the condition, you’ll need to hover over the Condition text area and then click the icon that appears to its right.

In the table, set it up as follows:

Totalgreater than or equal3000.00;

Save the condition.

One of the crucial things in defining the initiation is setting the context to only the web store. This means that records created through the web store will be the only ones that trigger the workflow: any estimates created through the NetSuite UI, CSV import, or any other context, will not initiate the workflow. This is important for our example workflow, but something you should also consider when creating your own workflow: when do you want the workflow to run? Keeping the contexts to precisely where you want them will help maintain the integrity of your data, as well as minimize any potential performance hit.

That’s the basics of the workflow created, so you can click Save. After that, we need to create a custom field to store the status of the approval.

Step 3: Create Approval Status Custom Field

Go to Customization > Lists, Records & Fields > Transaction Body Fields > New and create it as follows:

  • Label — Approval Status
  • Type — List/Record
  • List/Record — Approval Status (create a new list with Pending Approval, Approved, and Rejected)
  • Store Value — (checked)
  • Applies To — Sale, Opportunity

Save the new record type.

Step 4: Begin Designing the Workflow

Go back to the workflow we just created. When editing the workflow, you’re shown the workflow manager where you can build out your workflow by defining actions, conditions and states.

The interface has two key elements:

  1. Diagrammer — the left panel, where you can add and edit states and transitions; in view mode, you can use it to learn more about the states, actions, and transitions of the workflow
  2. Context Panel — the right panel, you can add, edit, and delete workflow elements; in view mode, you can read element information

When the elements are added and built out, note that you’re able to click and drag them, and click to view and edit them. You may want to use this time to familiarize yourself with the interface.

Step 5: Create Workflow States

Our workflow needs three additional states to represent the possible statuses that the estimate could end up in after being created.

To start, double click on State 1 to edit it, and rename it to Estimate Creation.

After that, use the New State button to create three new states, naming them after our new statuses: Pending Approval, Approved, Rejected.

Step 6: Create Actions and Transitions

After creating the states, we must now connect them together. We do this with actions and transitions. This is the longest section in the tutorial and it’s essentially the bulk of the work.

When the estimate is created, we need it to transition to either the Pending Approval state or the Approved state. But we also need to perform some changes to the record.

Double click on the Estimate Creation state, which opens the state’s window, and then:

  1. Click New Action
  2. From the list of available actions, select Set Field Value
  3. In the Field dropdown, choose the newly created Approval Status field
  4. In the Value subsection, select the Static Value radio button and then choose Pending Approval from the Selection dropdown
  5. Save

In the Transitions tab, click New Transition to add a new transition. We’ll need to do this twice, one to send it to Pending Approval, and the other to Approved.

For Pending Approval:

  • To — Pending Approval

The rest of the basic information can be left blank.

Under Condition, we will need to set the condition on which this will trigger. You can use formulas if you know how, but it’s probably easier to use the visual builder. Click the icon next to the Condition text area to open a new window to set the formula.

We’re going to write a quite complicated condition using logic, so check the Use Expressions to show more complex options.

This table lets us construct the formula by designating what records, fields and values are required, as well as which operators to include (AND/OR) and where to insert parenthesis. Note that if no record is selected in a row, the system will assume you mean the current record (which in our case is the estimate).

Construct the formula as follows, adding in three rows:

(Totalless than or equal7000And
Sales RepSupervisornot emptyAnd
CustomerOverdue Balanceless than or equal0)Or
Totalgreater than7000.00

If you read this from the top row, left to right, you can see how the final condition builds up like a sentence to form:

(Total <= 7000.00 And Sales Rep : Supervisor Is Not Empty And Customer : Overdue Balance <= 0.00) Or Total > 7000.00

Save the condition and transition.

You may wonder why we have not included the $3000 minimum requirement in here: remember, the basic workflow condition (which we set earlier) has set this requirement, so we don’t need to set it in the transition condition.

Create another transition, this time sending it to Approved.

The conditions for this are similar, except we are automatically approving it if the sales rep does not have a supervisor.

(Totalless than or equal7000And
Sales RepSupervisoremptyAnd
CustomerOverdue Balanceless than or equal0)

Which results in:

(Total <= 7000.00 And Sales Rep : Supervisor Is Empty And Customer : Overdue Balance <= 0.00)


Back in the workflow manager, you’ll see that the states are now connected.

After that, we need to create workflow actions so that the users can trigger these transitions — this will mean creating buttons.

Edit the Pending Approval state and click New Action. In the window, you can see all the different things that we can set up to do when the workflow is in this state. Click on Add Button.

Set the label to Approve and then edit the Condition. You can use the formula view, if you wish, but simplicity sake, we’re going to use the visual builder again:

(User Roleany ofAdministratorOr
Sales RepSupervisorany ofCurrent User)

Thus, we get:

(User Role = Administrator Or Sales Rep : Supervisor = Current User)

After saving, create another button with the same condition, but changing the label text to Reject.

When you’ve created both buttons, edit the transitions to associate the buttons with them. Naturally, when editing the transition to the Approved state, you’ll need to associate the Approve button by selecting it from the Execute on Button dropdown.

Repeat this for the Rejected transition.

Next, we need to trigger the emails that will be sent to the sales rep when the estimate has been approved or rejected.

Edit the Approved state and create a new action for Send Email.

The important configuration options are in the Sender, Recipient and Content sections.

  • Sender — (select a sender from your organization, or use the current user, which would be the approver)
  • RecipientFrom Field
    • Record (Join Field) — Current Record
    • Field — Sales Rep
  • Content — Custom:
    • Subject — Estimate {TRANID} Approved
    • Body — Estimate {TRANID} Approved

You can use whatever you like in the subject and body fields, but I’ve included some very simple examples. The {TRANID} will, as the name suggests, translate to the ID of the transaction in question. There are others like this that you can use, as these are the internal IDs of the fields on the records.

After saving this action, repeat it for the Rejected state, swapping out the appropriate text.

The final bit of setup you need to do is change the value of the Approval Status field to either Approved or Rejected. Again, we do this with a workflow action.

Create a new action for the Approved state, this time selecting the Set Field Value option.

The only significant configuration options are in the Parameters section. Select Approval Status from the Field dropdown, and then, in the Value subsection, select Static Value > Selection > Approved.

Save and then repeat the process for the Rejected state.

Phew. That’s all you need to set up this workflow!

With everything saved, begin the process with a test customer to create a quote meeting the conditions we laid down. For example, different order values, sales reps that have supervisors and those that don’t.

If you’re happy, change the release status of the workflow to Released.

Tips and Tricks

Flo has graciously included some additional pearls of wisdom, which you should note before embarking on your own workflow.

Execution Conditions and Context

Make sure you are specific about the conditions and the context you want your workflow to run on. Firstly, from a simple operation perspective, getting them right means that they’ll run when you want them to. This means that if you don’t need them to run during CSV imports, don’t set that as an option (or, rather, have them trigger on only the web store context). Having it run at times when you don’t want could compromise the integrity of your data, and create more work for you and your staff.

Secondly — and just as importantly — is performance: having the workflow start at times when you don’t need them to can slow down your instance.


When you change the release status to Testing, logging is enabled by default. Make sure that when you change it to Released it is turned off, or else you’ll end up with some very noisy logs.

Remember: client-side actions are not logged.


Although we didn’t do this in our example, we do recommend creating clear and unique names for the IDs and names for all your workflows, states, actions, and custom field fields. There is always a chance that you could run into a conflict when installing a bundle, if that bundle contains a workflow or new custom field.

Execute as Admin

In our example, we told the workflow to run as if it were an administrator — this was necessary as we needed to access records that require additional privileges. For your workflow, consider whether it is necessary. Overusing it is bad for security, and could inadvertently lead to unintended data access for the users initiating the workflow.

Scheduled Workflows

If you don’t need your workflow to trigger at specific, individual points in time, then consider using a scheduled workflow. Scheduling your record and field transformations at a quiet time for your business can improve end-user experience.

Just make sure that you schedule it at the appropriate time for your business, and that it runs at a necessary frequency. Having it run too often can degrade performance.

Also keep in mind that client-side triggers don’t work in scheduled workflows.

Finally, for it to run, make sure that you set it to Released.

General Tips for Approval Workflows

If you’re going to build an approval workflow, there are some specific tips. For example, think carefully about how many states are required: trying to condense states in a smaller number can lead to unexpected behavior, and adding too many could end making it unnecessarily complex.

There are some native fields, such as Next Approver and Approval that mean that you don’t need to create your own (and duplicate functionality!). These fields are specific to some records, so we couldn’t use them, but check to see if they fit for yours.

Read the documentation and learn what the best practices are for approval workflows, such as locking the transaction when approved using Do Not Exit states, or, at least, adding workflow conditions so that it’s not possible to enter and re-enter the workflow over and over.

There are also samples of other approval workflows in the documentation.

Execution Order of Scripts and Workflows

An advanced tip for troubleshooting: if you have scripts and workflows deployed at the same time, and they have the same triggers and contexts, the scripts will be triggered before the workflows. In other words, if they both set the value of a field, for example, then the final value will be the one set by the workflow.

Final Thoughts

Workflows seem like a novel customization avenue for NetSuite Commerce developers. After all, there’s no coding involved — but that’s deliberate as the workflows effectively like a wrapper/interface for the SuiteScript that ultimately gives workflows their power.

As we said, they can be a great way to empower non-technical users to make and maintain their own customizations because of the easy-to-use GUI. As developers, this may be preferable as it means that your users are free to get on with the changes they want, and you can get on with other work.

Just keep in mind when they’re a good fit and when they’re not, and make sure you read up on all the documentation we have on the subject.