In this example, we will build a quick workflow that create an approval task for a single line item.  One client I worked with recently requested that certain items need to be reviewed by their design team to ensure the configuration of the item was correct, so they wanted a way to notify the design team when one of these items was ordered AND also not let the item be shipped until the review was complete.  To do this we leveraged the Create Record action using the sublist action group for the items sublist on Sales Orders.

First we created a custom checkbox on the item record called "Needs Review"

One other helpful customization is to create a custom Transaction Line field that we can use to store the Task record we will create in future steps.

Then in our workflow we created a sublist action group using the Before Record Submit trigger

Next we added the Create Record action to our sublist action group, ensuring to set the condition to check for the "Needs Review" checkbox on the item record

For the remaining parameters we leveraged the native Task record in NetSuite to generate the review task for the design team.  This was especially nice because the native functionality surrounding Tasks allows for easy reminders, notifications and even allows the user to perform the review using their mobile device if they have the NetSuite App on their phone or tablet.  The nice thing about the Create Record Action is you can set field values on the newly created record right from the configuration window.  As you can see we've set many fields on the Task record like the Title, Message, Due Date, Assigned To, etc.

One other step is to stop the order from being processed.  You can do this by either marking the line as Closed or setting the entire order to Closed until the review is complete.  Another option is to leverage the Pending Approval status of the Sales Order to leave it and Pending Approval until the review can be completed.

Once last step we can take is to use a Scheduled transition to move this order into a "Review Completed" state.  The saved search used as the condition of the transition simply looks for Review Tasks that are marked completed and then if true, triggers the transition.

Then in the new REVIEW COMPLETED state you can remove the "Closed" checkbox from any line to let the order be processed by your operations team.

This solution can be adapted to many different use cases and customized to fit many different applications and requirements.  We are always eager to hear how you've used workflows and different actions within your organization.  Please take a moment to comment or write us with your ideas.  Also we are always available to help with any questions or needs you may have.  Please let us know how we can help but clicking the button below.

The Create Record action can only be used with server based triggers to ensure that there is no data lost during the client interaction with the form.  For more information on workflow triggers read our blog post on Triggers, Contexts and Event Types.  The Create Record action is also limited to only some of the Record Types, but not all.  Most of the limitations revolve around transactions as those are more complicated to create so automating those is a little more difficult.  However, almost any Custom Record, Entity Record or Activity record is available to be created which opens up a world of possibilities for customization and improved efficiency.

In this example we will pair a custom record with a scheduled workflow to store and manage Average Cost for items and how it changes over time.  Average Costing in Netsuite is very helpful and easy to understand when it comes to your inventory value, however, it is a "moving target" as purchasing and sourcing changes over time.  It is hard to know and understand how your costs have changed over time, so we can make a custom record to store this data and report on it later.

• To start first make a custom record that links to the Item Record and holds the Date and Current Average Cost.

• Next we need to make a Saved Search that will define all the items we want to track the Average Cost History for.  You can add whatever criteria or Results columns you need to fit your business use case, but for our example we will only track Active items with the Average Costing method.

• Now we can create a workflow and set it to Scheduled.  Also defining our Saved Search as the criteria.  We will also create this average cost history every month on the 1st day of the month.

• In our first state we can add the Create Record action

     

• Because this is a Scheduled workflow we will use the Entry trigger so the custom record is created as soon as the Item enters the workflow

• In the parameters of the action we will define the following:
• What record type we want to create (ie. our new Item Average Cost History custom record)
• The Item assigned to our new custom record (ie. the Current Item being processed)
• The current date
• The Average Cost of the Item being processed

• Now when the workflow runs you can see the custom record is created automatically and attached to each respective Item.

While this is just a simple example of how to use the Create Record action it can also be used in a more "real-time" sense by using an Event Based workflow instead of a scheduled workflow.  You can add this action into approval workflows if you would like to capture approval history as a custom record.  You can use the Create Record action to create a new custom record at ever state of the approval so you know who was the current user, the date/time and the status change at that time.  This can store much needed information to help you review and track what happened to a record throughout the approval process.

There are many other uses and processes that can be improved by using this powerful action.  What are some ideas or scenarios where you have used the Create Record action?  Put your input and ideas into the comments, we love to get feedback and insights for other Netsuite users.

Most of the Go to Page actions we've deployed over the years are just quickly linking reports and saved searches to other records so users don't have to remember the menu path for specific reports.  For example, Finance teams have asked to provide a link or button on Customer records that would open up the A/R Aging report as that is a common workflow for their daily processes.  To do so we can create a simple 2 state workflow on the Customer record.

In state 1 of your workflow add the Add Button action.  (You can read through our article on the Add Button action if you have more questions on how that works)

Then add a transition into State 2 that executes on button click.

In State 2 we will add the Go to Page action.

Next we will use the Entry trigger as we only want the redirect to happen right when the button is clicked and not every time the record is loaded or edited.

Then we will select the A/R Aging page in the list

Now the button appears on Customer records

And when clicked the user is taken to the native A/R Aging report.

Now one big issue is that this is just the A/R Aging Summary in whole, where many users would prefer to see the A/R Aging summary filtered to the exact customer that they click the button on.  As stated above this is not possible with the native functionality and can be overcome by using our Go to URL action, but in this case the entire aging will have to do.  But at least the user doesn't have to remember the menu path to get to this report and if you have customized the report you can link to the custom report instead of the standard one which can make navigation easier as custom reports sometimes get buried in the custom reports menu.

One trick you can use is you can create a custom center link that navigates you to almost any URL either internally to your NetSuite environment or externally.  To do this first go to Customization > Centers and Tabs > Center Links

Then in a new line enter a custom label for the link and the actual URL.  This URL can be any external webpage, or any internal URL to NetSuite.  We've seen accounts link to a new transaction record already in edit mode, or even documents stored in the file cabinet so there a lot of possibilities here with what you can add to these Center Links

Now in our workflow we can add our new link as the Page to redirect to instead of the A/R Aging report.

As a side note you can only use the Entry, Exit and After Submit triggers with this action.  This is because you need the record to be saved to the database before redirecting away from it.  If you were to use a Before Submit, or After Field Edit trigger then any new information you entered onto the record would be lost as you are redirected away by the workflow.  Usually, if you are trying to give the user a button to click then the Entry trigger is best, but if you want to be redirected as the record is being saved then After Record Submit is best.  If you have any more questions about workflows, how to leverage workflows in your account or any other customizations, please contact us at anytime.

The next step is to build your custom field that will sit on the Employee record.  To do so navigate to Customization > Lists, Records and Fields > Entity Fields > New

Enter a name and ID for your field then select the Currency type. (NOTE - you can also use Decimal Number as well)

Next we need to select the Employee record under the Applies To and UNCHECK the Store Value box.  This is key to getting this to work so make sure you uncheck this box so NetSuite can dynamically source the correct value every time the record is loaded.

The last step is we need to add the saved search we made under the Validation & Defaulting subtab

Once saved you can view the Employee record to see the value automatically populated.

While this is incredibly helpful when viewing records we run into a problem in that this field is NOT reportable.  Meaning it does not display a value when added to a report or saved search.  This is because we unchecked the Store Value box on the custom field configuration.  This is because the value cannot be dynamically sourced if it is stored, BUT if it is not stored then it cannot be reported on.  To overcome this "catch 22" we can leverage workflows.  Then nice thing about workflows is any non-stored field is still dynamically sourced during the workflow execution and then can be used as a condition or even used to set the value of another field.

To do this we need to first create a saved search that will trigger our workflow.  The criteria of this workflow would be any Employee that is a Sales Rep. (NOTE - The results and filters to do not matter in this case, but you can customize those as you feel comfortable.)

The make another Custom Entity Field that will be used to store the value being calculated by the saved search.  Be sure to keep the store value box checked.  (Make sure the field type matches the field type you created in your non-stored field).

Lastly, create a scheduled workflow based on the Employee record and use your saved search as the criteria.  Also setup the frequency you would prefer.  We will use Daily at 11:00pm, so every night the total sales will be calculated and stored.

In the first State add a Set Field Value and use the Entry trigger.  (NOTE - We do not need to use any extra Conditions, Contexts or Event Types as this is already controlled by the Saved Search and Schedule we setup in the previous steps)

In the parameters find your stored field and then use the From Field parameters to set the value from your non-stored field

Then save your workflow.  Now every night at 11:00pm the workflow will run on ALL employee records where Is Sales Rep = T.  The Employee Total Sales field will be calculated from the first saved search we built, then the calculated value will be stored in the Employee Total Sales (stored) field.  This way you can report on the stored field in other saved searches or reports.  You can also set the frequency of your workflow to be more often if you need more "real-time" information.  This same concept also works in Event Based workflows but requires a user to create or edit the record to trigger the workflow to store the new value.

One other thing to note is you can set the field display type of the non-stored field to "hidden" in the field configuration and that field will not be shown to users as they view employee records but still can be accessible to workflows as normal.

This little trick is an amazing leap forward in automating and optimizing data throughout your system, as you can now automatically calculate and store data between many different record types with your NetSuite environment.  Be sure to follow us and check back often for more great tips and tricks to help you maximize your NetSuite investment!

As stated before the Do Not Exit Workflow checkbox is found in the header of each State within your workflow.  It can be checked at anytime as long as the State does NOT contain any transitions assigned to it.

The field help and documentation on this checkbox are pretty self explanatory stating, 

"States that are designated as non-exiting must have no transitions. When the record in the workflow enters a non-exiting state, the record will remain in the state forever and the workflow will not terminate."

Here we can clearly see that when a State is marked with "Do Not Exit Workflow" then the record will remain in this state indefinitely and the workflow will never terminate.  Any actions within the state will continue to execute forever, as long as they are not using the Entry or Exit triggers.  As such, if an action is trigger On Entry, it will be executed when the record first enters this state, but then NEVER again as the record will never leave the state so re-entry is not possible.  Alternatively, because the record will never Exit this state the On Exit trigger will never be executed either.  However, all other Server and Client triggers are still effective if any Actions are triggered from these events.

Lastly, if you were to add a transition to a State that is marked with the "Do Not Exit Workflow" checkbox then it will immediately become unchecked and also disabled so you cannot check it again as this State is no longer available for this setting.

The most common misconception about this setting is that it is a huge drain on system resources to somehow "remember" what records held in what states of workflows and constantly be in a "holding" pattern forever.  This is just simply not true.  In fact, the system functions in almost the opposite way.  When you enable the Do Not Exit Workflow setting the Current State is stored with the record when it is saved to the database.  This record is not touched or interacted with by the system in anyway until a user tries to "recall" or view the record.  In this case the record is loaded from the database and the Current State is still stored with it.  At this point the system is able to quickly evaluate the actions within this state and perform them easily, with low impact to the over system performance.

Conversely, if one were to NOT check this box then in the same scenario the record will be stored to the database with NO reference to a workflow or workflow State.  Then when "recalled" to be viewed by a user, the system must find all workflows that the records meets the criteria of and initiate them all.  This usually will create an instance and history record for the workflow initiation and then once initiated the actions within the workflow will be evaluated and executed accordingly.

So as you can see the Do Not Exit Workflow box could avoid all this unnecessary processing of workflow initiation, instance records and extra evaluation of conditions if used in the correct context.  In conclusion this may seem like small distinction in functionality, but these small configuration can lead to big payoffs when evaluating the performance of your system.

If you have questions about workflows or ANY type of customization or automation within your NetSuite ecosystem reach out to us and we would be happy to partner with you to optimize your environment.

In the initial setup and configuration of your workflow there are two settings you can use to enable these helpful tools.  They are the "Keep Instance and History" setting and the "Enable Logging" setting.

With these two settings you can implement NetSuite's backend logging capabilities to help you review what happened to the record throughout the workflow and where you may have configured an action or transition incorrectly.

NetSuite offers a few different configuration settings for this function to give developers more flexibility around when and how Instance records should be kept for records within your workflows.  The available options are:

• Always - which means workflow history will always be kept under the System Notes tab of the record being affected by the workflow and saved there indefinitely.
• Never - the system will log the workflow history for a record while it is actively within the workflow, but once it leaves the workflow or the workflow is canceled all instance and history records will be deleted from the database.
• Only when Testing - the system will only maintain workflow history for records while the workflow release status is set to Testing, but not for any other release status.  When the workflow is transitioned to the Released status the system will log the workflow history for a record while it is actively within the workflow, but once it leaves the workflow or the workflow is canceled all instance and history records will be deleted from the database.

To expand upon the wealth of information that workflow history records can provide you can also dive deeper into each action and transition executed in each state by using the Enable Logging feature.  When this checkbox is checked the "Log" link will appear next to each workflow instance under the Workflow History sublist.

When you click on this link a popup will appear that shows every action and transition contained within that state and what condition was met to trigger each action.

Here we have an enormous amount of information showing each action performed the trigger used, the condition met and even the values set by each workflow action.  We can also see transitions and why they were triggered and in what context.  This is incredibly helpful during the troubleshooting phase of your development to see where you might have configured something incorrectly or the logic of a condition might be a little off.

You can also toggle the "Show Rejected Actions/Transitions" checkbox to see actions that are setup within the workflow state, but maybe did not executed and the reason why the did not execute.

This logging is the most helpful tool for troubleshooting workflow issues and errors.  We usually recommend that you enable logging for the initial development of workflows and also for the first few weeks after deployment of any workflow to help quickly fix any issues that may arise during the "hyper-care" phase after implementation.  However, once a workflow has been running successfully for a few weeks or even a few months it might be a good idea to disable logging as the workflow instance logs and workflow logs do take up database room and require system resources to create, access and maintain.

A very little known feature of workflows is the fact that you can delete or remove these logs and history records for workflows from the system if you feel they are no longer needed.  This can be very helpful when performing system clean up efforts or just trying to remove unwanted "junk" from your system.

In your workflow if you hover over the "more..." link in the upper right hand corner you can select the "Instance and History Records" option from the drop down menu.

In the pop up window enter the number of months in the past you would like to keep these instance and history records, or enter zero in this field to delete ALL history records for this workflow.  Then click the delete button.

Upon successful completion of the deletion the pop up window will disappear and you can continue to configure your workflow as needed.

As you can see workflow history and workflow logs can be extremely helpful to troubleshoot any issues or errors that may arise from your workflow, but make sure to only use them when absolutely necessary.  It does not help to load your system up with years worth of workflow logs when you are only experiencing a few errors or issues throughout the year.  It would be better to turn off logging and when issues arise try to quickly enable logging and recreate the record or transaction the same way to catch the error, then disable logging again after a fix is in place.

If you appreciated this insight into workflows or would like to learn more about workflows and other NetSuite customizations be sure to subscribe to our blog or follow our LinkedIn page for more great content.

The use case for this action is pretty straight forward and concise.  When the condition is met -> send an email.  And the trigger used is also fairly straight forward as well, either send the email as soon as the record is saved, when the record transitions to a new state OR on a schedule.

In this example we will look at using the Send Email action within an Event Based workflow and a Scheduled workflow.

An event based workflow can be initiated by someone either creating a record or viewing/updating an existing record.  In this case we want to include both events in our workflow initiation as this example will be sending an email to a Vendor when a Purchase Order is saved.

In the first state of the workflow click the New Action button then select Send Email from the list

We have added a custom field to the Purchase Order called "Email PO".  It is a checkbox that we will use as the condition of our send email action.  We will also use the After Record Submit trigger because we want the email to be sent right after someone saves the Purchase Order IF they have checked the "Email PO" box.

Now in the Parameters we have to first define the Sender and Recipient of the email.  This is where the workflow action falls a little short of Saved Searches, because you are forced to select from a list of current users or contacts (or a field on the record that contains a reference to a list of contacts) as the sender.  Wherein Saved Searches allow you to type in any email address/author into the Sender field for sending an email.  This is not a huge burden to overcome as any email you would like to use as a sender can easily be added as an Employee record OR a Contact record in Netsuite and then selected in the workflow action.

The recipient section provides more options for configuration, as you can select from a list of entities already in the system (ie. Employees, Customers, Vendors or Contacts), enter a free form address, OR use a field on the record to source the recipient email address.
NOTE - the field on the record must be either a Email Address field type OR a List/Record type with reference to an Entity list.

You can also type a free form address into the CC or BCC fields and they will be copied on the email.  Alternatively, you can source a field value by using the field id in the CC or BCC fields to get an email address that is stored in a field on the record.
NOTE - This field does NOT have to be an Email Address type field, but the value of that field must be a valid email address or else the workflow will fail to perform the action

Now we can move onto the content of the email.  You can either use a template that you have already setup under Documents > Templates > Email Templates, or use a custom template that you build right within the parameter's of the workflow.
We will make a custom template and enter a custom Subject line and use the field ID to source the PO# into the Subject of the Email

Then add text into the body of the email, again sourcing field values from the Purchase Order into the email body by using the field IDs

We will leave the "Include View Record Link" checkbox unchecked as we are sending this email to an external recipient.  If you check this box a "View Record" link will be added to the bottom of the email that when clicked will attempt to take the person into your NetSuite environment to view the Purchase Order.  We have a safeguard here in that most likely the Vendor will not have a valid login, however, it is best to leave this off the email to avoid confusion.  If this email is only going to Internal users like an email requesting approval of a transaction the the View Record link might be helpful for that user to easily find their way to the record and approve it.

Lastly, we can add attachments to the email that gets sent.  First, we will discuss the Attach File paramter.  Here we can attach any file stored in the File Cabinet to this email by selecting it in the File parameter.  Alternatively, you can use a Document type field on the record to store a File from the file cabinet and then use that field as the source of the file that should be attached.  This is especially helpful if the file being attached is not always static but rather conditional based on certain criteria on the Purchase Order.
In this example we will set it to just one file which is our Supplier Terms file so each PO is sent along with our Supplier Terms.  (Remember the file will be attached using the format that it is stored in the File Cabinet so if you have a Word Doc stored in the File Cabinet a Word Doc will be attached to the email.)

You can also choose to include a copy of the transaction as an attachment as well.  The options are:

• Inline Above - This means a copy of the Purchase Order will be generated using the Advanced PDF Template set on the Transaction Form but it will be displayed within the body of the email ABOVE the written text you defined in the Body parameter.
• Inline Below - This means a copy of the Purchase Order will be generated using the Advanced PDF Template set on the Transaction Form but it will be displayed within the body of the email BELOW the written text you defined in the Body parameter.
• Default - The system will evaluate the Default Email Preferences of the Entity assigned to this transaction and use that preference to determine what type of document should be attached to the email.
• PDF - The Purchase Order will be attached as a PDF file to the email
• HTML - The Purchase Order will be attached as an HTML file to the email

You can also use a Scheduled Workflow to send an email based on a specific schedule.  In this example we will use a Scheduled Workflow to send out Shipping Notifications to our customers at the end of the shipping day.

To do this first create a Saved Search that will be used as the criteria of our workflow.  In this case we are looking for Item Fulfillments in Shipped Status where the date is TODAY.

Now in the configuration of our workflow you can set the Saved Search as the criteria and set a schedule of Daily.  Now everyday at 4pm the system will run the Saved Search above and if any records meet the criteria of that Saved Search it will trigger the actions within the workflow.

In the Send Email action we will use the Trigger of "Entry" because this is a Scheduled Workflow and the After Record Submit trigger is not valid for Scheduled Workflows.  So we want to trigger the email as soon as the record enters the first state of the workflow.  Also we are leaving the condition blank because the Saved Search that is initiating the entire workflow already has the condition that we need.

Now update the Sender, Receipient, Subject and Body of the Email to contain the proper information for your customers to receive a shipment notification.

We will also include the transaction as a PDF (which in this case will be a packing slip since this is running on the Item Fulfillment transaction).

Now our Shipment Notifications are easily sent to our customers at the end of everyday.

As you can see this Send Email action is much more powerful and versatile than the email functionality built into Saved Searches and can provide a TON of communication to both your internal users AND your external Customers and Vendors.  One major gap in this action is the ability to choose different PDF templates when generating the attachment for this email.  Unfortunately, NetSuite only allows you to use the PDF template attached to the transaction form set on the record.  This can cause some headaches in that you either need to be constantly changing the Custom Form field on transactions to meet certain use cases, or struggle with a seriously customized PDF template to cover all use cases.

At MGBC we've created an easier way to manage this requirement.  We have created a custom workflow action the generates a PDF document of the current record using ANY PDF template that you have defined.  Then once you have generated that PDF document and stored it in a custom Document Type field on your record you can use it in the Attachment parameters in your Send email action.  This way you can create and store PDF files of your transaction in ANY PDF template with completely customized criteria, then send them to your Customers and Vendors using the native Send Email action as described above.

Checkout our custom Create and Attach PDF workflow action today.  OR email us at info@mgbcpro.com to learn more.

One of the nice things about these actions is that they are able to be executed from almost any client trigger and even a few server triggers.  Below is a list of triggers and how they interact with the record being affected by the workflow.  If you would like more information about how triggers work while working with records in NetSuite read our blog post on Workflow Triggers, Contexts and Event Types.

Now that we've gone through each trigger in detail we will go over which triggers are appliable to these three workflow actions
NOTE - These actions are not available for Scheduled triggers.

Now let's discuss what each action actually does.

• Set Field Display Type - this will change the way the field is displayed to the user while interacting with the record.  There are 4 options for this action:
• Normal - the field will be displayed normally in both View and Edit mode and there are no restrictions on Editing it
• Disabled - the field will be displayed normally in View mode, but in Edit mode the field will be "grayed" out and will not be able to be edited.  (NOTE - Disabled fields can still be updated by workflow actions)
• Inline - the field will be display as Inline HTML text in both View and Edit mode.  The user will not be able to edit or change the field value when the display type is Inline
• Hidden - the field will be hidden from the user in both View and Edit mode.
  
  
  
• ​Set Field Display Label - this will change the field name or label that is shown to the user in both View and Edit mode (depending on the trigger used).
  
  
• Set Field Mandatory - the field will be mandatory and cannot be left empty.  You can also toggle a field to be NOT mandatory as well.

The parameters of these actions are all very similar and managed pretty much the same.  The first step is to define the trigger to be used, or WHEN the action should be performed.  Then define any specific contexts or events that should trigger this action.  Lastly, define a condition that tells the workflow what criteria should be used to trigger the action.

In this example we want to make the the Class field mandatory when the Department is set to "200 Operations".  In this case we will use the After Field Edit trigger with the correct condition.  This way when someone edits the Department field the workflow will evaluate if the Department is "200 Operations" and if it is, trigger the action to make the Class field mandatory.
(Be sure to set the Triggering Client Field to Department as we want this action only to be triggered when someone updates the Department field)

Next we need to define the parameters of the action.  Here we will tell the workflow WHAT field needs to have the mandatory flag toggled and whether to turn ON the mandatory setting or turn OFF the mandatory setting.

(Leaving Mandatory checkbox unchecked will make the field NOT mandatory.  Leaving the Mandatory checkbox checked will make the field mandatory.)

As an added bonus you can toggle between Sublist and Body fields within these actions to change the field Display Type, Label and Mandatory setting for fields within the Items sublist on transactions, just like you can affect body fields.  

With this setup we can make the Job (or Project) field on each line when the Department of "200 Operations is selected

The Set Field Display Type has a few different parameters (described above) but functions similarly to the Set Field Mandatory Action.  Using the same After Field Edit trigger and Triggering Client Field of Department, but changing the condition to Department is NOT "200 Operations", the Class field will now be Hidden when the Department is changed and does not equal "200 Operations"

Lastly, we will change the Display Label of the Class field to "Financial Segment" when the Department is set to "900 Finance".  This way when someone selects the Finance department on a Transaction the Class field will be displayed as "Financial Segment" for more clarity to the financial user, but without having to add new custom fields to the record.

All these actions may seem small or "ticky-tacky" improvements to your system, but they can make a BIG difference when it comes to data consistency and accuracy.  Ensuring that users are always entering the correct information into the correct fields and NOT missing anything when required is a huge benefit to your NetSuite eco-system.  As the saying goes, "Garbage in, garbage out."  This will stop the garbage from even entering you system to keep it clean and maintained on an ongoing basis.