We often hear from our customers that, when the need to add custom functionality in NetSuite arises, it can be difficult to determine whether the requirements can best be met via scripting or through the creation of a workflow. Our Consultants have broken down the different requirements to help your team determine which tool would serve best when evaluating the need to add custom functionality.

 

What is the difference between a workflow and a script?

First, we should define how each of these tools function in NetSuite. Workflows are easier for non-technical users to create and maintain, allow for better traceability in audit logs, and generally (although not always) require less effort to create.  Scripts can do things workflows cannot, but generally must be created and maintained by a technical resource, may generate audit trail entries that are more difficult to decipher, and will most likely require more effort to create.

 

When trying to decide whether your requirements can best be met via a script or workflow, consider the following:

1. Header or Line-Level?

The first thing to determine is whether your customization will interact with line-level transaction fields.  While NetSuite has improved line-level workflow functionality over the past few releases, it is generally true that customizations involving line-level data require scripts.

For example – say you would like to make a certain line-level field required on journal entries based on the subsidiary selected at the header level.  While a workflow could be triggered based on header-level subsidiary selection, it could not change a line-level field from optional to required – such a change would require the use of a script.

 

2. How Many Joins?

Workflows are most effective when they reference data no more than one “join” away from the primary record on which they operate; scripts can work across multiple “joins” as necessary.

For example – say you create a custom record to store information regarding customer verticals, with a specific vertical assigned to each customer. Let’s also assume different fields should be displayed on sales orders based on either the vertical assigned to the associated customer or on specific information stored on that vertical’s record.

In the first case, since the vertical itself is accessible on the customer record, the value is only one “join” from the sales order and so can be accessed by a workflow.

In the second case, however, we have to go from the workflow, to the customer, to the vertical, which constitutes two “joins” – one more than can be accommodated by a workflow.  In such a case, a script would be required.

 

3. New UI Elements?

Workflows cannot create new user interface elements (other than custom buttons); scripts can be used to generate such elements via “Suitelets.”

Say, for example, you would like to present the user with a new pop-up window in which they can record additional purchase-related details when they select a particular header-level Department on a PO.

The new window will be used to create a custom child record to which users can refer later.

While such functionality is beyond the capacity of workflows, it can easily be achieved via a simple custom record and an associated script.

 

Conclusion

In sum, workflows are simpler to build and maintain and allow for easier auditing than scripts, but have limits to their functionality and generally fall short when working with line level data, multiple joins, or custom UI elements.

Learning how to evaluate which is the best fit for your requirements can help get your customization efforts off on the right foot and can ensure that you resource your project correctly. For more tips on how to best manage your NetSuite, read about our Premium NetSuite Support services here: https://squareworks.com/support/