To start you will need to add the RSS Feed portlet to your dashboard as it is usually not part of the default configuration.  To do this click the personalize link in the upper right had corner of your dashboard.

Then select the RSS Feed tile and click on it to add it to your dashboard

Open the setup menu for the RSS Feed portlet

In the setup menu you can choose from a list of predefined sources of popular business or sports websites.  For this example, scroll to the top and select the (Custom) option.

Then enter the following URL into the URL Feed field

http://fetchrss.com/rss/659825561e7a55294a4feda3659826e8b076375f6d2ac4c2.xml

This URL will source the MavenCloud blog into your dashboard so you can stay up to date on the latest articles and tips on optimizing NetSuite.

Choose the number of articles you want to see by setting the Number of Links field.  Also be sure to check the Show Details checkbox.

Click Save and you will now see each article as it is posted with links to navigate directly to each article.

The feed will be refreshed every time you login to NetSuite OR you can click the refresh link in the portlet to get the latest data.  If you would like more information on how to build a dynamite dashboard or any other enhancements you need for your business use the link below to contact us.  We have the resources and experience to help you with any configuration or customization project.

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.

One great trick we've deployed many times is to combine the power of saved searches with workflows to get an easy to manage system for adding, removing and changing the recipients for emails.  This customization is fairly easy to setup and leverages many native features so you know it will remain stable throughout future releases.

The idea here is to use the Contact records associated with the entity to keep an up to date list of contacts and what transactions they want to be notified of.  To start we will create a custom list called "Email Group".  This will help us categorize contacts into logical groups for sending emails.  (You can also leverage the native "Role" field on contacts for this as well if you prefer).

Next we will create a custom field on the contact record that we can use to select what group each contact should be a part of.

Now we can add our contacts associated with our customer and assign them the proper email group

The next step is to create a saved search of contacts and make it a summary search so we can use it to source the value of the transaction body field.  In the criteria we want to exclude Inactive contacts, but include contacts with the Order Notifications email group.

Then our results tab will include one summarized field using the NS_CONCAT function.  This will concatenate all the results of the search into a single comma separated field value.

Lastly, don't forget to give your saved search a filter so the system knows how to filter the results to get only the contacts applied to the correct company/customer.

Now let's create a custom Transaction Body field that will hold the results of our saved search.  Make sure to UNCHECK the store value checkbox so the value is dynamically sourced whenever the record is loaded.  We used a Long Text field type just in case there were a lot of unique email addresses to be notified.

Also we need to define the saved search we created in the Validation & Defaulting subtab.  Remember to choose what field on the transaction should be used to filter your results.  Since the Available Filter in your saved search was based on the Customer field, we should choose the same field in our custom field configuration

Now our Sales Order form will dynamically source ALL email addresses that are tagged with the "Order Notifications" email group.  And these addresses will automatically be filtered to only the contacts associated with the Customer defined on the transaction.

Then in your workflow you can add a Send Email action and assign the new transaction body field as part of the recipients.  Note how we are using the CC Address parameter within the action and using the field ID of our new transaction body field to define the addresses to be copied.  This is a great way to circumvent the restrictions placed on trying to select a field from the list in the From Field parameter.  We have tested using this method in the Free Form Address field and the workflow will return an error.  However, using the field ID in either the CC or BCC fields seems to work just fine.

Since an email does require a Primary Recipient you do need to define a recipient in one of the fields other than the CC or BCC.  You can use a native field as pictured above OR you can put in a static address of purchaseorders@mycompany.com.  This way all communication emailed out of NetSuite is stored in a shared inbox for your company to review if needed.

The power of this functionality comes with the ease of maintenance for our users.  For instance if Curtis Johnson were to leave the company and we need to add a new contact, it is as simple as managing the native Contact list on our Customer record.  Curtis Johnson can be inactived and a new contact created with the same email group.  Or if the accounting team wants to be made aware of new orders place, then they can easily receive the "Order Notifications" tag.

Now when the next order is placed they will all be notified via email.

If you would like to learn more about the Send Email action you can read our blog post specifically on this topic.  Also if you would like help with or have questions about leveraging the customizability of NetSuite to build no-code automation in your environment please reach out.

For a quick review on Client Triggers they are the following:

• Before User Edit
• Before Field Edit
• After Field Edit
• After Field Sourcing
• Before User Submit

As stated before, the ability to be able to manipulate sublist fields within the Items sublist on transactions was a HUGE leap forward for workflows and their application within your NetSuite environment.  This also opened up a whole world of possibilities for Administrators and Functional Consultants working with NetSuite as before they needed to depend on development resources to do anything more than just header level fields.  One of the little know features of the Set Field Value action is that Client Triggers can help to manipulate sublist fields while the user is entering lines into the Items sublist.

One great example of this is if you have minimum order quantity for an item that needs to be regarded when ordering items.  With a workflow we can set the quantity of a line on a purchase order based on a custom field from the Item Record, to make sure our purchasing team is maintaining our vendor relationships properly.

First let's start by adding a custom field to our Item Record called Item MOQ that we will use to capture the minimum quantity to be ordered.

Now create a workflow on the Purchase Order record. In the first state of your workflow add a Set Field Value Action.

Now set the Trigger to any After Field Edit as we want to update the Quantity field after a user sets the Item field.

Now here's where the trick is.  Most people miss this little step in Workflow setups, but under the Triggering Client Fields you can select either a Body or a Sublist field as the trigger.  That means when the field selected is Edited it will trigger the action to execute as long as the Condition is met.  Without this Trigger Client Field set the workflow does not know which field to "watch" to know when to fire the action.  In our example, we will choose the Item (Line) field because we want the Quantity on the line item to be updated after the Item is selected.
NOTE - When you change the Triggering Client Fields to Sublist you must select which sublist and this will reset your conditions.

Now that we have our general configuration complete, let's setup our parameters.  First select the Quantity (Line) field which is going to be the field we want set by our workflow.  Then using the Item (Line) Join we can get our new Item MOQ from the Item Record.

Now we can save our workflow and test out the functionality.  Remember to turn on workflow logging for your testing period to review any errors or skipped actions for troubleshooting.  If you have any questions about workflow logging, learn how to properly manage workflow instance and history logs in our blog post.  We can see that when entering a purchase order for our item the quantity field is updated to match the MOQ when the new item is selected on the line.  However, for other items the quantity is NOT changed.

If you have any questions about workflows or need help implementing these features in your NetSuite environment please reach out and we would be happy to help you through any obstacle or provide advice on how workflows can transform your business.

One of the key elements to remember about the Set Field Value action is the trigger that you use to perform the action.  It is widely versatile and supports every trigger available to workflows.  Use the table below to understand how each trigger effects the functionality of this action and how you can leverage different triggers to perform the action in the way that you want.

In this example the requirement is that we have a custom field on the Customer record that stores the Class segment assigned to each Customer.  Using a workflow we want to set the Class field on all Sales Orders created to match the Class from the Customer record.

To setup this action properly, start by adding the Set Field Value action into your workflow state.

Next choose the correct Trigger you would like to use for this action.  In this example we will use the Before Record Submit.  This is usually considered the lowest impact to overall system performance as it does not require additional loads of the record AND it fires quickly as the record is being saved.  Also this way you know the field value will be set successfully each time as the user cannot disrupt any actions being triggered after they submit the record

Now we can choose the correct Event Type and Context to meet your business use case.  You can read more about Event Types and Contexts in our article dedicated to this topic.  Because we do not need the Class field set every time someone views or edits a Sales Order we can use the "Create" Event Type to limit the impact to system performance and only set the value when the record is first created

We will also add a condition to this action so that it only fires if the Customer Class is NOT EMPTY.  There is no reason to try and set a field value if the sourcing field also does not have a value.

Alternatively, if you are more comfortable with building saved searches you can use a saved search condition as the criteria for your action.  This can be especially helpful if you have a very complex condition or multiple conditions that effect this action.  Also you can use a summary search as the condition as well which can be even more powerful to summarize data about a record and use that criteria as the basis of your condition.  Because the criteria here is very simple we will just stick to the regular condition builder.

Next we will use the parameters section to pick the field we want to set the value of.  Remember this is the field we want to change the value of NOT the field we are using as the source of the value we want.

Now we can use the rest of our parameter fields to make sure we set the correct value.  We can leverage anyone of the vast array of options here.

• Static Value - set the field to the same value every time.  There are different options for different field types (ie. checkbox, date, text, number, etc)
• From Field - get the value from another field on the current record OR a joined record
• Formula - use a formula to set the value.

As you can see just this one small action has MANY different configurations, use cases and options to help you maximize the way your team uses NetSuite.  Fortunately, this post is 1 of 3 blog posts on the Set Field Value action.  Because its use and setup is so expansive compared to other actions we are going to expand this into 3 Blog posts.  Check our Part 2 on this versatile action that covers using the Set Field Value action in the Items sublist.

Adding links within your saved search can not only help users navigate through NetSuite quickly and easily, but also provide quick access to records and information directly related to the content searched and displayed within your saved search.  One of the most common ways to utilize links within saved searches is to provide a link to a joined record.  For example, if you have created a Item Search then the native Edit/View link provided by the system will only navigate to the Item record.  

However, you may be joining to related transactions within this search and may want to give the user an easy way to open the transaction record.  This is easily done through a Formula (HTML) and an "href" element.  Add a Formula (HTML) into the results of your saved search and then use the following formula:

'<a href=''https://system.netsuite.com/app/accounting/transactions/transaction.nl?id='|| {internalid} ||'&whence=''>View</a>'

A few things to note with this formula:

1. You can also replace "system" in the URL with youraccountnumber.app where youraccountnumber is the account number of your NetSuite environment. (ie https//1234567.app.netsuite.com/app/accounting, etc)  This will restrict your link to ONLY work within the environment you have entered.
2. The text entered between the <a> and </a> elements is what is displayed to the user to click on.  You can change this to whatever you like.  You can also use double pipes to concatenate a field value here as well.  So instead of the link saying "View" you can have it list the Document Number of the transaction by instead changing the formula to:

Now the Transaction Number will be displayed AND it will be clickable to the user, redirecting them to the transaction listed in the results row of the saved search.

To help manage the user experience you can also update the <a> element with a notation so a new window is opened.  This way the user does not have to go back and reload the saved search after viewing or updating the transaction.  To do so we need to add a target attribute.  The resulting formula HTML would look like this:

'<a href=''https://system.netsuite.com/app/accounting/transactions/transaction.nl?id='|| {internalid} ||'&whence='' target="_blank">'|| {number} ||'</a>'

Another nice trick to help the user experience is to open the record in Edit mode to save the user from more clicks to make changes to the record.  To do so we can add a parameter of "e=T" into the URL.  The resulting URL would be:

'<a href=''https://system.netsuite.com/app/accounting/transactions/transaction.nl?id='|| {internalid} ||'&e=T&whence='' target="_blank">'|| {number} ||'</a>'

Now that we have a good grasp on how links will work we can work on turning this into a button instead of just hyperlinked text.  To do this we need to add a <button> wrapper around the Link Text so it is displayed as a button instead of hyperlinked text.  The resulting URL would be:

'<a href=''https://system.netsuite.com/app/accounting/transactions/transaction.nl?id='|| {internalid} ||'&e=T&whence='' target="_blank"><button type="button">'|| {number} ||'</button></a>'

Now we have a button displayed instead of hyperlinked text showing in our saved search.   Also, when clicked a new window will open AND the record will be opened in edit mode so the user can quickly and easily update the information.

You can also change some of the formatting of the button by using the "style" attribute inside the <button> element.  Some applicable attributes would be:

• font-size
• font-weight
• font-style
• color
• background-color

So you could give your button a color with a style attribute and the resulting URL would be:

'<a href=''https://system.netsuite.com/app/accounting/transactions/transaction.nl?id='|| {internalid} ||'&e=T&whence='' target="_blank"><button type="button" style="background-color:red">'|| {number} ||'</button></a>'

And the user would see a formatted button in the saved search

One more feature you could add into this would be to open a pop-up window for the record instead of a new window or in the same window.  To do this you would add a "onclick" attribute into the overall <a> element.  The syntax can be quite tricky but the resulting formula would be:

'<a href="#" onclick="window.open(''https://system.netsuite.com/app/accounting/transactions/transaction.nl?id='|| {internalid} ||'&e=T&whence='',''selection'',''dependent=yes,height=600,width=800,scrollbars=no,statusbar=no,titlebar=no,menubar=no,resizeable=yes,location=no'');"><button type="button" >'|| {number} ||'</button></a>'

The the user can open/edit the record right within a pop up window, make their changes, then quickly close the window and return to the saved search quickly to keep working through the rest of the result.

You can also use the parameters within the "onclick" attribute to help control the size and functionality of the pop-up window by changing the "height", "width", "location" or other parameters.

If you would like more information on how to leverage saved searches within your NetSuite environment or need help with any customization or enhancement feel free to reach out to us at any time.  Also be sure to subscribe and follow our blog for more great tips and tricks.

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.