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.

• 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.

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.

Now that we understand how to test and deploy workflows let start setting up an approval workflow for Expense Reports.  Another nice feature NetSuite provides is you can leverage native fields and G/L impacting settings, while still building a completely customized workflow.  Under Setup > Accounting > Accounting Preferences go to the Approval Routing tab.

Then enable the Approval Routing feature for the transaction(s) of your choice.  Once enabled we can begin to build our workflow.

• Start by navigating to Customization > Workflows > Workflow > New and give your Workflow a name.
  
  
• Then in your workflow configuration select the Type as Transaction and the Sub Type as Expense Report.
  
  
• Next we want to choose Event Based as the initiation type and mark the Create and View/Edit checkboxes.  This means the workflow will initiate when a new Expense Report is created OR when it is Viewed and/or Edited.
  
  
• Here you can also set specific criteria (either condition based or by creating a Saved Search with the criteria you want) on the Expense Reports that should trigger the workflow.  For example if you only want approval for Expense Reports created in a specific subsidiary, then set that subsidiary in the Condition field.  You can also define a Trigger Type that will define when in the process of creating a storing a record the workflow will trigger.  These additional options can get complex so I usually try to leave these as "open" as possible.  These types of restrictions on the overall workflow can conflict with conditions within the workflow on specific actions.  I try to leave the overall workflow configuration as unrestricted as possible and then use conditions within the actions, transitions and states to manage these specific scenarios.
  
  
• Now click the Save button and your workflow will be saved and the workspace will be opened with one Initial State pre-populated.
  
  
• Your first state will be the Initiate state, which will be like an intake state for new Expense Reports and here you can start to perform initial actions and filter all Expense Reports into the correct subsequent states.  Double click on State 1 and then Click the New Action button.
  
  
• In the Actions list select the Set Field Value action.  Then choose the Approval Status field as the field to set the value of.  And set a static value of Pending Approval.
  
  
• Next we will choose the Entry selection for Trigger On as we only want the status to be set when the record first enters the state, NOT every time it is Viewed or Edited.  Here is where you can add conditions for each action that gives you more control over how your workflow interacts with Expense Reports, rather than putting overall conditions on the workflow itself.
  For more information on Workflow Triggers, Event Types and Contexts read our post about how to use these parameters most effectively.
  
  
• Click Save on this action.  Then select New Action and select the Add Button Action.  In the parameters set the Button Label as "Submit for Approval".  We will also use the Before Record Load trigger so the button is added while the record is loaded from the database.
  
  
• The Save Record First checkbox can provide nice functionality for the users.  If you check this box the "Submit for Approval" option will be added to the Save & menu at the top of the Record.  (For example there is Save, Save & Print, etc.  If you check the Save Record First button, there will now be an option for Save & Submit for Approval)
  
  Give this state a name and Save it
  
  
• Now let's add another state into the workflow so we can make a transition to it, by clicking the New State button.
  
  
• Double click on the initiate state and then click on the New Transition button

• Select State 1 as the state to transition to the select the Submit for Approval button under the Execute on Button drop down.  Now your Expense Report will remain in the INITIATE state until someone clicks the submit button, upon which it will transition to the next state.
  
  
• Now double click on your State 1 and lets add 2 set field value actions just like we did before.
• The first is to set the Approval Status field to Pending Approval on Entry
  
  
• The second is to set the Next Approver field to the Employee's supervisor on Entry.  To get the Employee's supervisor use the Field Join section in the parameters to get to the Employee record and grab their supervisor.
  
  
• ​Next we will add 2 buttons.  (1 for Approve and 1 for Reject).  Also remember to add a condition to your Add Button actions so they only appear of the current user is the Next Approver.  This way only the employee assigned to the Next Approver field can see the Approve or Reject buttons.
  

• The next step is to add 2 new States (1 for Approve and 1 for Reject) to the workflow and 2 new transitions to the appropriate state.
  Here is a great place to insert the MGBC Pop Up with Input Prompt custom action so collect a rejection reason.  See our relatedBlog Post about capturing rejection reasons.
  

• Open your APPROVED state and add a Set Field Value Action to set the Approval Status to "Approved"
  
  
• Also open your REJECTED state and add a Set Field Value Action to set the Approval Status to "Rejected"
  
  
• Lastly, it is recommended that you use the Do Not Exit Workflow checkbox on both Approved and Rejected states so the transaction does NOT re-enter the workflow after approved and show up with a new "Submit for Approval" button.  This was the transaction will always remain in the Approved (or Rejected) state until you make a new Transition to move it into a different state.