A good rule of thumb is if you'd like the action to happen while the user is interacting (or editing) the record that is usually a client trigger, but if you would like the action to happen before OR after the user interacts with the record, it is considered a server trigger.
(NOTE: You can only initiate workflows on server triggers.)
Client triggers are very helpful to use to "guide" the user on how to fill out the form or record. Actions like setting fields as mandatory or sourcing a value into a field when another field is edited or changed, are great ways to enhance the user experience during the data entry process. They can also provide much needed control over your data entry to increase your data integrity.
Server triggers are great to use when you don't want to involve the user in the change or update. If you would like the user to fill out the form or record with the data they have, and then use that data to provide "default" values or source values into other fields, this is where a server trigger will shine.
Server Triggers
- Before Record Load - when the user clicks on the view or edit link for a record and it navigates to a new page. The loading of this record is considered Before Record Load.
- Before Record Submit - when the user clicks the Save button on the record but BEFORE the new data is saved to the database.
- After Record Submit - when the user clicks the Save button on the record the new data is first saved to the database, then the record is loaded again and performs the action.
- Entry - NetSuite is tracking what state the record is in or transitioning between so when it enters a new state it can trigger an action.
- Exit - NetSuite can trigger an action to happen while the record is "leaving" one state as it transitions to another.
- Scheduled - the user can define a time based trigger to schedule when an action or transition should occur.
| Trigger Name | Applies To | Description |
|---|---|---|
| Before Record Load | Workflow Initiation Actions Transitions | Triggers while a record is loaded in the browser upon create or edit. Usually used for setting default fields on records. |
| Before Record Submit | Workflow Initiation Actions Transition | Triggers when a user clicks the Save button but BEFORE the data is saved to the database Usually used for validating form data or even calculating fields before save |
| After Record Submit | Workflow Initiation Actions Transitions | Triggers when the user clicks the Save button but AFTER new data is saved to the database. Usually used for transitions or actions dependent on or using new data that is entered onto the record. Like sending an email or creating depending on records. |
| Entry | Actions Transitions | Occurs when the record first enters the workflow state. This trigger fires at the same time as the first server trigger. Usually used in approval workflows to set statuses or fields dependent on the step of approval process the record is in. This allows actions to be performed when a record moves from Pending Approval to Approved but NOT every time the record is loaded or edited. |
| Exit | Actions Transitions | Occurs when the record leaves the workflow state. Usually used in approval workflows to set statuses or fields dependent on the step of approval process the record is in. This allows actions to be performed when a record moves from Pending Approval to Approved but NOT every time the record is loaded or edited. |
| Scheduled | Workflow Initiation Actions Transitions | Trigger an action, transition or initiate a workflow on a schedule |
| ALL | Workflow Initiation | Initiates on any triggering event. (Only used for workflow initiation.) |
Client Triggers
| Trigger Name | Description |
|---|---|
| Before User Edit | Executes when the record form loads into the browser. Use this trigger, for example, to make changes to the record form in the browser before the user edits any field. (This is the only trigger we've successfully used to change the Custom Form dynamically before the user interacts with it.) |
| Before Field Edit | Executes when user tabs or clicks away from a field after entering a value. Use this trigger, for example, when validating the value of a record field. |
| After Field Edit | Executes when a user enters or changes the value of a field. Use this trigger to help enhance the data entry experience by dynamically performing actions in real-time as fields on the record are being changed. |
| After Field Sourcing | Executes after a field change, after all of the child field values for the field are sourced. Use this trigger, for example, when setting field values based on other sourced values. |
| Before User Submit | Executes every time a user clicks Save when the form is in the state. The actions execute in the browser, before any data is sent to the NetSuite database and the save operation occurs. Use this trigger, for example, when validating record form field values. |
Event Types
You can extend the detail and control of the actions and transitions by leveraging the event types available in workflows. These event types represent specific NetSuite events that can affect records and therefore you can only trigger an action when these specific events happen. For example, if you only want to perform an action when someone creates a drop shipment, or when a user copies a record from another record then this is possible using Event Types.
Simply set the event type in the multi-select field and the action will only respond when that specific event occurs. If you do not select ANY event type then NetSuite will consider ALL events as available to trigger the workflow, action or transition.
The event types available are:
| Event Types | Trigger Types | Description |
|---|---|---|
| Approve | Before Record Submit After Record Submit | A record is approved using native approval functionality. (Applies to only transactions listed in the Approval Routing tab of Setup > Accounting Preferences) |
| Cancel | Before Record Submit After Record Submit | A transaction is cancelled |
| Copy | Before Record Load | When a record is copied from another record |
| Create | Before Record Load Before Record Submit After Record Submit | A new record is created |
| Delete | Before Record Submit | A record is deleted |
| Direct List Edit | Before Record Submit After Record Submit | A field on a record is updated using inline edit within a saved search |
| Drop Ship | After Record Submit | A purchase order is created using the drop ship link |
| Edit | Before Record Load Before Record Submit After Record Submit | A record is edited using the "Edit" button in the normal UI |
| Edit Forecast | Before Record Submit | A forecast is edited using the bulk edit forecast feature |
| Before Record Load | An Email is sent | |
| Mark Complete | Before Record Submit | A task is marked complete |
| Order Items | After Record Submit | A transaction is created using the order items screen |
| Pack | Before Record Submit | An Item Fulfillment is marked packed |
| Pay Bills | After Record Submit | Bill payment records are created using the bulk pay bills screen |
| Before Record Load | A user clicks the print button | |
| Reassign | Before Record Submit | A lead or prospect is reassigned to a new sales rep |
| Reject | Before Record Submit | A transaction is rejected using native approval functionality. (Applies to only transactions listed in the Approval Routing tab of Setup > Accounting Preferences) |
| Ship | Before Record Submit After Record Submit | An Item Fulfillment is marked shipped |
| Special Order | After Record Submit | A purchase order is created using the special order link |
| View | Before Record Load | A record is viewed or loaded in the UI |
Contexts
You can also specify a certain context to trigger actions or transitions. This is especially useful when you have a lot of different types of interactions or integrations with your system. For example, you can trigger an action only when a record is updated using CSV import, or if a record is updated by web services (ie. integration).
Be careful when using contexts as you don't want to limit yourself too much. Maintaining workflows with lots of context restrictions can be difficult and time consuming. As your business and processes evolve so will your requirements so constantly changing contexts on actions can become tedious very quickly.
The table below describes all the execution context types in more detail:
| Context | Description |
|---|---|
| Action | Represents when a record is changes via an action within a workflow |
| Bank Connectivity | Represents when a record is changed via the Bank Connectivity plug-in |
| Bank Statement Parser | Represents when a record is changed via the parser plug-in or Bank Statement Parser plug-in |
| Bundle Installation | Represents when a record is updated via a bundle installation script |
| Client | Represents when a record is updated via a client script |
| CSV Import | Represents when a record is updated via CSV import |
| Custom GL Lines | Represents when a record is updated via the custom GL lines plug-in |
| Custom Mass Update | Represents when a record is updated via mass update. |
| Debugger | Represents the SuiteScript Debuger |
| Email Capture | Represents when a record is created or updated via the email capture plug-in |
| Financial Institution Connectivity | Represents when a record is created or updated via the financial institution connectivity plug-in. |
| Map/Reduce | Represents when a record is created or updated via a map/reduce script |
| Other | Represents a context that is NOT one of the other contexts listed |
| Payment PostBack | Represents a payment PostBack task |
| Payment Processing | Represents a payment processing task |
| Platform Extension | Represents a platform extension customization in Commerce |
| Portlet | Represents a portlet script. |
| Promotions | Represents a promotion in Commerce |
| Rate Adjustor | Represents when a record is updated via the currency rate adjustor |
| Rest Web Services | Represents a REST Web Services request |
| RESTlet | Represents when a record is created or updated via RESTlet script. |
| Revenue Management | Represents an Advanced Revenue Management task |
| Scheduled Script | Represents when a record is created or updated via Scheduled Script |
| SDF Installation | Represents an SDF Installation (SuiteApp Install) script |
| Shipping Partners | Represents when a record is updated via a Shipping Label Integration task |
| SOAP Web Services | Represents a SOAP Web Services request |
| Suitelet | Represents when a record is created or updated via a Suitelet script. |
| Tax Engine | Represents a SuiteTax Engine Task |
| User Event Script | Represents when a record is created or updated via a User Event script |
| User Interface | Represents when a record is created or updated via the normal user interface that most interact with. |
| Web Application | Represents when a record is created or updated using a web application in commerce |
| Web Store | Represents a web store task in Commerce |
| Workflow | Represents a workflow task. |
As you can see there can be a very high level of complexity to your workflows with all the different features and options available. Be very careful in using Event Types and Contexts in your workflows as if you set too many limitations it can be hard to troubleshoot when actions or transitions to not trigger as expected. Also, as your business grows it will be very difficult to remember and maintain all these specific limitations. As a best practice we recommend leaving the Event Types and Contexts selection blank (so ALL will be considered) and utilize the Triggers to limit when actions and transitions should occur.
We find it more useful to limit workflows by Event Types and Contexts in only very specific use cases and to even segment those into their own workflow so you can remember to maintain and manage them correctly, without it getting mixed into more general workflows.
If you need more help getting started with workflows, be sure to read through our Creating Your First Workflow post to start with a basic approval workflow and get a good foundation to build upon.