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.

• Now that we have subscribed to the Event we can transition our Service Request record to the next state when an update to the Event occurs.  For example, if the Service Tech marks the Event as "Completed" then we can use that action to trigger our Service Request to transition to the Completed state.

• Now in the Completed state we can lock the Service Request record (or perform any other actions) that are necessary.

• Overall the workflow ends up looking like this and really helps drive a consistent process for your customer service reps.

• Create another workflow based on your Event record.  Use a Go to Record action to redirect the service rep to a Sales Order transaction so they can create a Sales Order to manage the billing of this service call.
• Tie your Sales Order(s) and Invoice(s) to your Customer Service Request Record with a custom transaction body field so you can get a complete picture of the Service Request from schedule to billing
• As mentioned above you can use Cases instead of a custom record for your Service Request, then you can leverage native Case functionality AND your customer can review the Case in the native Customer Portal.

One more thing we'd like to mention is the additional features you can unlock by using Tasks or Events in NetSuite for your Service Techs.  Not only does this help you manage schedule and calendars easier because it has NetSuite native calendar and availability functionality, but it also works with the Employee Center AND the NetSuite Mobile App.  Any workflow and button you deploy to a record in the native UI will also be available in the NetSuite Mobile App as a button/action item.  

This way you can save on license cost and your Service Techs can utilize mobile devices while on-site to perform many functions throughout the Service Call such as:

• Provide detailed notes and or diagnosis codes
• Enter time worked or hours needed to complete the job
• Add follow up details or flag an event as for a Customer Service Rep to follow up
• Also the ability to add parts used on a service call if necessary.

• To start we will create a few new Transaction Body fields to help us manage our recurring invoices.  These should be added to the Estimate or Sales Order, whichever you would like to use to manage your recurring invoices.  (Or you could use a custom Transaction Type if that fits your use case better.)
• Recurring Invoice Frequency - this will be how often (in days) an invoice gets created
• Next Invoice Date - this will be used to trigger the workflow to create a new invoice.
• Recurring Invoice End Date - if recurring invoices should stop at a certain point you can use this field to define an end date.

• The next step is to setup a Saved Search that will trigger your Invoice creation.  Setup a transaction saved search based of the transaction type of your choice and include the new Next Invoice Date field you created as part of your criteria.

• Now let's setup a workflow that will create Invoices.  For this we will use the Transform Record action.  To start just create a workflow with the type Transaction and sub type that matches the transaction type you are working with.
  Remember that you can only transform an Estimate or Sales Order into an Invoice.  (Also if you setup a custom transaction type using the "Sales Transaction" type it can be used to transform into an Invoice)

• Then set your workflow up as a Scheduled workflow that runs everyday, because we will use the custom field Next Invoice Date to control when recurring invoices are made so we want to check every day if any need to be made.

• Create a Workflow State field that will first store the current Next Invoice Date so we can recalculate it later.

• The first thing to do is to copy the Next Invoice Date in the Current Next Invoice date workflow field we made in the step above.

• Now we can add our Transform Record action into State 1 of the workflow.  The transform record action will essentially just take the Estimate and almost Make Copy of it, except the "copy" is an Invoice instead of another Estimate.  You can set new values for header fields on the invoice that gets created but unfortunately you cannot change any of the line items so be sure that the Estimate you setup has the correct Line information on it.

• Add another action to the workflow to set the NEW Next Invoice Date by adding the Frequency to the workflow field that we created.

• Now let's setup an Estimate for our first recurring invoices.  The Estimate will always remain in the system and be there to generate Invoices each month.

There is a lot more customization that you can do with this functionality, but what we've built here can maintain the basic functionality of automated recurring Invoices.  If you have a Payment Processing Profile setup you can also use this functionality to automatically charge the customers credit card.  In that scenario you would want to transform the Estimate into a Cash Sale instead of an Invoice, but the concept is still the same.  Also, if you've read our blog post on Invoice collections you can utilize that workflow to make sure your Invoices are paid on time.

We love to find creative ways to leverage workflows to get the best out of NetSuite without having to invest in more modules or 3rd part apps.  The power of workflows is pretty amazing and the things you can build with them are quite impressive if you take the time to know and understand their functionality and limitations.  If you read through our other Blog posts you can quickly realize the amazing functionality that comes built in with every NetSuite account.

Now let's take a look at how you can leverage the power of URL parameters in your workflows.  The key here is to give the user an easy and intuitive interface to guide them through the correct process to maintain consistency and accuracy.  This is where workflows in NetSuite really shine because they provide a graphical workspace to build out your process and monitor your records as they flow through each state.  With our Enhanced Workflow Actions bundle you can use the MGBC Go to URL action to redirect the user to any URL; both internally to other NetSuite pages OR externally to other systems.  We have also provided you a way to dynamically source URL parameters into the redirect URL so you can pull data from the existing record and use it as part of the URL.

One simple example of this is to manage your Customer records between NetSuite and Hubspot, a popular CRM system.  Do do this you would need login credentials to your HubSpot account and then generate a quick workflow to add a button to your customer records.

1. Create a Customer based workflow with 2 states
   
   
2. In start state put an Add Button action Before Record Load.  We also added a condition of "Web Address is NOT empty" because we are going to be using the Web Address in our custom action
   
   
3. Create a transition from your start state to State 2 that is executed upon button click
   
   
4. In state 2 you would add the MGBC Go to URL action, upon Entry
   
   
5. In the parameters of the Go to URL set the URL for a new HubSpot company and add the url field from NetSuite as Parameter 1 in the URL.  This will dynamically source the Web Address from the current customer record into the new Company record created in HubSpot.
   
   
6. Also be sure to add the correct URL parameter and syntax for dynamically sourcing values at the end of the HubSpot URL.  (Remember that URL parameters are always after the "?" in the URL.
   
   
   
7. You can also setup the Redirect Type as a Popup Window, New Tab or Current Tab so provide an even better user experience.
   
   
   
8. Now let's test our workflow with a new customer that we would like to also sync into HubSpot.  We can enter the Customer record in NetSuite with minimal information then use our new sync feature to copy data into HubSpot and provide more detailed information there for our CRM requirements.
   
   
9. Now if we click our new Sync to Hubspot button a popup window opens showing our pre-filled form for adding a new customer.
   
   

You can also perform a similar function with email as well.  You can quickly "integrate" your email account with NetSuite by using the "mailto:" URL.  This will allow you to open up your default email pre-populated with a To address, Subject and even Body message.  Also, because you are using the MGBC Go to URL action you can dynamically source the To Address, Subject and/or Body of the email from data already on the current record in NetSuite.

1. First, create your workflow on whatever record type meets your business use case.  (For this example, we will use another 2 state workflow with a button to transition between states)
   
   
2. Upon Entry of the second state add the MGBC Go to URL action and define the URL and parameters.
   You can use "mailto:[1]?subject=[2]" as the URL and [1] will represent any email address field on your current record, while [2] can be any text field like the Transaction ID or Memo; or use a formula to concatenate multiple pieces of information together.
   
   
3. Now when your button is clicked your default email provider is opened with the To: and Subject line already pre-filled based on your NetSuite data.
   
   

While using URLs and URL parameters for external systems can be useful, it is MUCH easier to utilize this functionality within NetSuite itself!  NetSuite supports a HUGE range of URL parameters and you can create some really amazing functions by moving data between different record types and even from records into saved searches.  Some of our favorite functions are:

• Create linked records like User Notes, Messages, Phone Calls or custom records with pre-filled form data
• Navigate to saved search results with pre-filtered data.
• Generate almost any printable PDF from ANY record or Saved Search PDF Template
• Automatically export data to Excel or add an "Export to Excel" button to records
• Create records or transactions that are currently not supported by workflows

This is just one very simple example of how powerful workflows can be, especially when you enhance them with custom actions that help you rise above the limitations of native functionality.  There are so many other possibilities available to you with our 9 other custom actions as well.

For example, use the Pop Up with Input Prompt action to help your sales reps define and re-define the customers budget throughout the sales process without having to remember to go back and update the customer record.  Simply provide a pop up window asking for the customers new budget number and when completed the new budget can be automatically updated right from the Task completion process, while simultaneously moving that Lead further through the sales workflow.  The use cases for all these actions within the sales process alone, are almost limitless.

If you need help defining your sales conversion workflow, or would like to hear more about how our Enhanced Workflow Actions bundle can help you manage your sales process, please email us at info@mgbcpro.com OR head to our website www.mgbcpro.com and check out our solutions page.

To utilize the MGBC Set Field Mandatory (any sublist) custom action you just need to gather a few parameters from the record you are manipulating with your workflow.  You will need to now the following information:

• The internal id of the field you would like to set as mandatory
• The internal id of the sublist your field is contained in

• One client we worked with had trouble with the department field not being set properly on Journal Entries by bookkeepers on their accounting team.  It was easy to overlook so they needed to set it as mandatory so it could not be forgotten.  However, they did not want this restriction on other users such as the CFO or Controller.
• To do this we created a new workflow and set it to the Transaction record type and Journal subtype.

Using our Enhanced Workflow Action bundle you can quickly create that much needed functionality to collect a reason for whatever decision is being made.  Actually, this custom action can be used within ANY workflow deployed to ANY record type within your environment.  The beauty of our Enhanced Workflow Action bundle is that you are only limited by your imagination.  You can provide rich, engaging workflows on custom record types, custom transactions, native transactions, entity records or even items.

To begin collecting responses to decisions within your workflows you can follow these simple steps:

1. In the Pending Approval state of your workflow remove the native Add Button action and replace it with the MGBC Button with Input Prompt custom action.
   
   
2. In the parameters section of the custom action define the following parameters
1. Button Label - This is the label displayed on the "Reject" button on your transaction
2. Popup Window Message - This is the text you want displayed in the pop up window.  This will direct the user as to what input is being requested.
3. Field to populate - this is any field on your current transaction where you would like to store the response text that the user inputs into the pop up window. (just enter the field ID of the field you want populated)
4. Input Received Validation Checkbox - this is a way for you to confirm that the user actually entered a response and didn't just click Cancel or close the window.  You can use a custom field or a workflow field to capture this value.  (just enter the field ID of a checkbox field)
   
   
3. Lastly, now that we are capturing a "validation" that input text was properly entered using our Input Received Validation Checkbox you can use that value to trigger other actions OR a transition to the correct state.  On the Transitions tab create a transition to the Rejected State when your Input Received Validation Checkbox = T.  Then your transaction will only be marked approved when you are sure the user has entered a rejection reason.
   
   

You can see how easy it can be to setup these types of prompts throughout your system to make sure that you are capturing all the correct data at the correct time.  Furthermore, because we are storing the rejection reason on each transaction record as they are moving through the workflow you can use these messages in other areas of SuiteFlow!  For example, why not capture the rejection reason using the MGBC Button with Input Prompt action and then use that reason in a native Send Email action so the requestor knows why their request was rejected?  

As you can see the sky is the limit, when it comes to what can be done with this fully configurable action that not only solves a long-standing need within approvals, but can provide much needed enhancements to ALL your workflows throughout ALL your processes in the business.

Let us know how you are using the MGBC Button with Input Prompt custom action in your environment OR ideas you have to leverage this in other workflows and areas throughout your organization.  Lastly, click the button below to find out more on our Enhanced Workflow Actions and how you can leverage all 10 custom actions in your account to automate even the most complex business processes.