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.

There is much more you can do with sublist action groups, but you can see that just setting field values dynamically within the items sublist can be VERY helpful to maintaining accurate data and cut down on the time spent entering data into forms.   Remember that when using sublist action groups all actions within the group are constrained by the configuration of the overall group so whatever trigger and even type you set on the overall group, be sure that it is applicable to all actions, or you will need to setup another action group for a different trigger.

If you would like to learn more about workflows, or how NetSuite in general can support your business feel free to reach out anytime.  We can support any customization, implementation or training for your environment.

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.

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.