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.

The Go to Record action essentially redirects a user to a new (or existing) record to continue their process or entry of data.  This can be used to create a new instance of a record type and then "join" it to your current record, OR simply to navigate to an already joined record.  For example, when entering an Estimate you select the Customer, this creates a "join" between the Customer and Transaction records as you are associating the Customer with that Estimate.  Now you can use this "join" to redirect the user to the Customer record from your Estimate either automatically or by the click of a button depending on your use case.

The Go to Record action is limited to only 3 triggers; 

• After Record Submit
• Entry
• Exit.  

This is because using another trigger with this action could result in loss of data.  For example if you were to redirect to a new record Before Submit, then the data you entered on the current record would NOT be saved and therefore would be lost.  In this regard, using After Submit circumvents this problem as the current record is fully submitted (or saved) to the database, then the user is redirected to the new record.  Entry or Exit triggers mimic the functionality of Before Load or After Submit (depending on the context) and therefore are also safe to use.

For this example, we will use the very popular use case of entering a rejection reason within an approval workflow.  It is a very common ask among NetSuite Admins and Developers to capture reasons when users are approving or rejecting transactions, however, there is not a lot of great solutions to this problem.  One of the most common solutions is to create a custom record that you would use to hold the response from the user and use the Go to Record action to redirect the user to this record within the workflow.

First we can start by creating a custom record called "Rejection Reason".  On it we will put a Long Text field for "Response" and also a List/Record field for "Reason Code".  Furthermore, we have a field to join this custom record to the Transaction it relates to so we can see the two linked together for future reference.  Remember since this is a custom record you can add as many fields and features as you want to collect the necessary information needed for your business.

The next step is to add this functionality into your existing approval workflow.  (Or if you need help building an approval workflow you can start with our blog on "Building your First Workflow".)  In this example we will open up our Rejected state where we have set the Approval Status to "Rejected" and Locked the record so no one can change it anymore now that it is rejected.

Then lets add the Go to Record action here so the Approval Status is changed automatically, but the user is redirected to our new custom record.

As mentioned before you can only use this action with a few triggers, but since the user is clicking a button which is transitioning them to the Rejected state we will use the Entry trigger.  This way when they click the button it will enter the new state and send them to the Rejection Reason record, however, it will NOT happen every time someone views the record, because it only triggers when it first enters the state. (Which is right after the button click.)

In the parameters of the action we will select our Record type.  This is the Rejection Reason record we created in the first step.

Now because we want the user to create a NEW instance of this Rejection reason we will mark the Open in Edit Mode box.  This will load a brand new instance of the Rejection reason record and it will already be in Edit mode to save the user from having to click edit.

**As a side note here, if you want the user to be directed to an already existing record (like we mentioned in the very beginning of directing a user to the Customer record joined to an Estimate) then you would use the Record ID parameters to do so.  To redirect the user to the Customer from an Estimate you would choose Customer as your record type, then Entity in the field.  So the workflow would use the Entity field on the Estimate to know what record the user should be redirected to.

However, since we do not want to go to an existing record, but instead create a NEW record we will leave the Record Type as "Rejection Reason" and the Open in Edit Mode = T.  
Lastly, using the Field sublist we can pre-define values on the new record being created.  For example, if you would like to provide a default value in the Response field on your Rejection Reason record, then you select Response in the Field sublist and then provide a value using either a field on the current record, a formula or a static value

In this case we want to make sure the Rejection Reason record is associated with the current transaction we are rejecting so we will set the Related Record field to be "Current Record"

Now the Rejection Reason record the user creates will be automatically associated with the Transaction they were viewing when clicking "Reject".  Also note that the Response and Reason Code fields are mandatory so the user cannot navigate away from this Rejection Reason without providing a value.

Also once the response is saved you can see it attached to the Transaction under the subtab you selected with configuring your custom record.

You can also pair this with a workflow you've created on the Rejection Reason record with another Go to Record action so the user is redirected back to the Transaction using an After Record Submit trigger.  This way after their response is recorded they are sent back to the original transaction they were working on.  Here is the setup for that workflow action.

While you can see that this solution is not ideal as there are a few potential places for the user to circumvent the process by closing a window too soon or a timeout from NetSuite.  Also, the user experience is a little clunky while still maintaining the overall objective.  But most of the time this solution is widely accepted and does provide a great example of how to capture responses in NetSuite without having to write any scripting.  As mentioned above our simple utility for capturing user input can be easily deployed to your account and used within any workflow or any record.  Check out this quick video on our Pop-up with User Input action.

If you would like more tips and tricks on how to optimize your NetSuite environment with workflows, automation and customizations then follow our blog or check back often.  We are also available to help design, implement and/or troubleshoot any customization at any level.  Just reach out to us with questions and insights on how we can help your business grow!

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.

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.