Get Control: Auto Approve NetSuite Transactions with Hold Rule Checks

This article is relevant if you are looking to gain better visibility and control over NetSuite transaction approval and validation processes.


After doing many client implementations and listening to all types of different concerns as it relates to accepting transactions meeting specific criteria, a pattern emerged that allowed us to produce an innovation to get in front of these types of challenges. ¬†To help describe the challenge, I will use the NetSuite Sales Order ¬†as an example. ¬†NetSuite offers a basic built-in switch to indicate if a Sales Order is approved. ¬†The Sales Order status is driven by an on / off dropdown field that has the value of either “Pending Approval” (unapproved) ¬†or Pending Fulfillment” (approved). ¬† ¬†NetSuite’s general thinking behind the switch is that when you are committed to deliver on a customer order, modify the Sales Order status to Pending Fulfillment. ¬†NetSuite offers tools to help this process to allow you to approve orders in bulk or individually. ¬†NetSuite doesn’t allow you to move to the the item fulfillment stage unless the Sales Order is approved; and, if you are working to manage a perpetual inventory, a Sales Order must be approved before inventory can be fully committed.

Naturally, NetSuite suggests to use the power of the platform (workflows or SuiteScript)  to drive any behavior around an order before it is approved.  Our team excels at discussing and producing business functions to drive transaction behavior as frequent readers know that I am passionate about the NetSuite customization platform. The most common technique used to manage the Sales Order is to check rules with workflow or scripts at the time the the order is going through BeforeSubmit  transaction event while it is moving between unapproved to approved status.  For example, one client had a rule that when an order is over $1,000 USD, a manager must be be the one to approve.  For another client, they were concerned that one big order would deplete all inventory on hand (the large order case).   Here, they invented a rule that if any order would consume more than 10 units (large in their case) do not allow the order to go through without manager review.

These two examples illustrate the need for transaction review by managers. ¬†Using the traditional approach, you throw an error if the user who is trying to approve the order is not a manager. ¬†Then, a manager can work transactions one at a time and by clicking the built-in “Approve” button and the same script will this time see that the user is a manager in a role with sufficient privileges to allow the approval to complete . ¬†Other examples include rules which ensure that the user gathered sufficient information but is not marked mandatory; for example, collect a purchase order number or ensure the customer has available credit. ¬†Using the same approach, you check th rule and throw an error during the approval evant and try to provide meaningful descriptions so the user can fix the transaction.

The General Challenge with Traditional Transaction Approval

With the background provided, I offer that the traditional approach is weak based on these points:

  1. Visibility: Most NetSuite administrators will argue that Workflows provide good visual indication of transaction approval states.  However, what about users and management ability to see what is going on while transactions are in play?  There is no offer.
  2. Role based Rule Override: there is no capacity to indicate which roles should be able to override transaction approval exceptions.  NetSuite administrators often produce multiple NetSuite forms to refine transaction edit capacities leveraging the permission system.  Over time, this approach becomes challenging and costly to manage.
  3. Auditability: Once a transaction has been approved, there is limited visibility about what happened.  Yes, system notes help, but they are not going to help you see how business rules passed their check.

Introducing Transaction Approval Manager

Based on the concerns noted above, we worked with a client and invented the Transaction Approval Manager.  We like to call it TAM (click to enlarge supporting images)  With this bundle available to our clients as no charge, we attack the challenge from a different perspective:
  1. Auto Approval: Instead of pushing orders to approval, the system works on your behalf to auto approve orders if they pass all validation checks.  Each validation check is considered a hold rule.
  2. Table Driven Rule Definition: Hold rules are now defined within tables allowing administrators more flexibility for ordering and driving behavior.
  3. Transactional Rule Exposure:  Based on the table driven rules, every transaction gets a copy of the hold rules so that each one can be checked.  Status on verification is visible to all users.
  4. Override by Role Management: The table driven rules allow for the definition of which NetSuite roles can override a transaction rule that does not pass.
  5. Auto Item Fulfillment Generation: based on the rules defined, if after a Sales Order is approved, it can automatically move to item fulfillment.  One approach is to approve a sales order but prevent an item fulfillment record from generating until a future ship date arrives.
Many times, we are building custom eCommerce integrations to NetSuite and TAM works great to make sure that high volume orders automatically go to item fulfillment if all is in order.  The staff then focuses on anything that does not pass the hold rules.

Get Control over Transaction Processing

While the Sales Order is the most common use case for TAM, the architecture can work to assist any NetSuite transaction type. ¬†We developed the bundle using NetSuite’s latest SuiteScript 2.0 technology which affords a more flexible and modular way to produce applications. ¬†In a TAM implementation, the key is to define the business rules that should be checked. ¬†Once these rules are in place and managed by TAM, you will begin to have better control over your day-to-day transaction management. ¬† You will find it much easier to train new users on what the business rules are and why they exist. ¬†If you have a use case for TAM, let’s have a conversation.

Be Sociable, Share!

Marty Zigman

Holding all three official certifications, Marty is Southern California's NetSuite expert and leads a team of senior professionals at Prolecto Resources, Inc. He is a former Deloitte & Touche CPA and has held CTO roles. For over 25 years, Marty has produced leadership in ERP, CRM and eCommerce business systems. Contact Marty to set up a conversation.

More Posts - Website - Twitter - Facebook - LinkedIn - Google Plus - YouTube

| Tags: , , , , | Category: Accounting, CRM, ERP, Infrastructure, NetSuite | 7 Comments


  1. Posted September 7, 2016 at 5:56 pm | Permalink

    So what I’m hearing is that this is a form of “exception management.” In other words, you can define rules by which if a transaction passes all of the rules (e.g., fields x, y, & z are populated and have valid data, flags A and B are checked, flag C is unchecked) then the transaction will automatically be approved, and if it fails the rule rule then it will go into an exception queue with the reason for failure. Brilliant!

    I’m assuming this could be applied to entity records as well as transactions? Actually I could see it potentially useful for just about any record type.

    Champing at the bit again!


  2. Posted September 7, 2016 at 7:44 pm | Permalink

    Hello Cash,

    Thank you for your kind words. Yes, you understand what I was hoping to convey. Indeed, it could be applied to any transaction type…


  3. Posted September 7, 2016 at 10:04 pm | Permalink

    Transactions for sure but what about entities, CRM records, custom records?

  4. Posted September 8, 2016 at 8:59 pm | Permalink

    Interesting thought. We probably could adapt it. But the the idea on entities and CRM records are less about approval and more about moving from one stage to another. Hence, the main looping structure could be paramertized to understand and reveal how you want to control the move from one stage to another.

  5. Posted September 8, 2016 at 9:42 pm | Permalink

    Sure. But there are certainly scenarios where vendors and customers can be “approved” or not (let’s say based on the D&B credit profile) and automatically approved if meeting a certain threshold. Also, custom records where let’s say you have an electronic signature integration and if something doesn’t meet a set of rules it needs to go to a manager for approval before sending. Oh the possibilities…

  6. Posted November 13, 2017 at 12:50 am | Permalink

    Excellent. Reminds me of when I use to work at Pega Systems. They have been very successful in applying a similar rules based approach to case management and sales – but in an enterprise context.

    Add in some AI to spot additional suggested rules – i.e. we notice a cohort of customers with a specific behavior need more attention or additional approval.

One Trackback

  1. […] couple these controls to tools to manage the order process. For example, many of clients use our Transactions Approval Manager (Record State Manager) to help ensure that orders meet all criteria: in this case, there are no unexpected order […]

Post a Comment

Your email is never published nor shared. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>