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!

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.

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.

The use case for this action is pretty straight forward and concise.  When the condition is met -> send an email.  And the trigger used is also fairly straight forward as well, either send the email as soon as the record is saved, when the record transitions to a new state OR on a schedule.

In this example we will look at using the Send Email action within an Event Based workflow and a Scheduled workflow.

An event based workflow can be initiated by someone either creating a record or viewing/updating an existing record.  In this case we want to include both events in our workflow initiation as this example will be sending an email to a Vendor when a Purchase Order is saved.

In the first state of the workflow click the New Action button then select Send Email from the list

We have added a custom field to the Purchase Order called "Email PO".  It is a checkbox that we will use as the condition of our send email action.  We will also use the After Record Submit trigger because we want the email to be sent right after someone saves the Purchase Order IF they have checked the "Email PO" box.

Now in the Parameters we have to first define the Sender and Recipient of the email.  This is where the workflow action falls a little short of Saved Searches, because you are forced to select from a list of current users or contacts (or a field on the record that contains a reference to a list of contacts) as the sender.  Wherein Saved Searches allow you to type in any email address/author into the Sender field for sending an email.  This is not a huge burden to overcome as any email you would like to use as a sender can easily be added as an Employee record OR a Contact record in Netsuite and then selected in the workflow action.

The recipient section provides more options for configuration, as you can select from a list of entities already in the system (ie. Employees, Customers, Vendors or Contacts), enter a free form address, OR use a field on the record to source the recipient email address.
NOTE - the field on the record must be either a Email Address field type OR a List/Record type with reference to an Entity list.

You can also type a free form address into the CC or BCC fields and they will be copied on the email.  Alternatively, you can source a field value by using the field id in the CC or BCC fields to get an email address that is stored in a field on the record.
NOTE - This field does NOT have to be an Email Address type field, but the value of that field must be a valid email address or else the workflow will fail to perform the action

Now we can move onto the content of the email.  You can either use a template that you have already setup under Documents > Templates > Email Templates, or use a custom template that you build right within the parameter's of the workflow.
We will make a custom template and enter a custom Subject line and use the field ID to source the PO# into the Subject of the Email

Then add text into the body of the email, again sourcing field values from the Purchase Order into the email body by using the field IDs

We will leave the "Include View Record Link" checkbox unchecked as we are sending this email to an external recipient.  If you check this box a "View Record" link will be added to the bottom of the email that when clicked will attempt to take the person into your NetSuite environment to view the Purchase Order.  We have a safeguard here in that most likely the Vendor will not have a valid login, however, it is best to leave this off the email to avoid confusion.  If this email is only going to Internal users like an email requesting approval of a transaction the the View Record link might be helpful for that user to easily find their way to the record and approve it.

Lastly, we can add attachments to the email that gets sent.  First, we will discuss the Attach File paramter.  Here we can attach any file stored in the File Cabinet to this email by selecting it in the File parameter.  Alternatively, you can use a Document type field on the record to store a File from the file cabinet and then use that field as the source of the file that should be attached.  This is especially helpful if the file being attached is not always static but rather conditional based on certain criteria on the Purchase Order.
In this example we will set it to just one file which is our Supplier Terms file so each PO is sent along with our Supplier Terms.  (Remember the file will be attached using the format that it is stored in the File Cabinet so if you have a Word Doc stored in the File Cabinet a Word Doc will be attached to the email.)

You can also choose to include a copy of the transaction as an attachment as well.  The options are:

• Inline Above - This means a copy of the Purchase Order will be generated using the Advanced PDF Template set on the Transaction Form but it will be displayed within the body of the email ABOVE the written text you defined in the Body parameter.
• Inline Below - This means a copy of the Purchase Order will be generated using the Advanced PDF Template set on the Transaction Form but it will be displayed within the body of the email BELOW the written text you defined in the Body parameter.
• Default - The system will evaluate the Default Email Preferences of the Entity assigned to this transaction and use that preference to determine what type of document should be attached to the email.
• PDF - The Purchase Order will be attached as a PDF file to the email
• HTML - The Purchase Order will be attached as an HTML file to the email

You can also use a Scheduled Workflow to send an email based on a specific schedule.  In this example we will use a Scheduled Workflow to send out Shipping Notifications to our customers at the end of the shipping day.

To do this first create a Saved Search that will be used as the criteria of our workflow.  In this case we are looking for Item Fulfillments in Shipped Status where the date is TODAY.

Now in the configuration of our workflow you can set the Saved Search as the criteria and set a schedule of Daily.  Now everyday at 4pm the system will run the Saved Search above and if any records meet the criteria of that Saved Search it will trigger the actions within the workflow.

In the Send Email action we will use the Trigger of "Entry" because this is a Scheduled Workflow and the After Record Submit trigger is not valid for Scheduled Workflows.  So we want to trigger the email as soon as the record enters the first state of the workflow.  Also we are leaving the condition blank because the Saved Search that is initiating the entire workflow already has the condition that we need.

Now update the Sender, Receipient, Subject and Body of the Email to contain the proper information for your customers to receive a shipment notification.

We will also include the transaction as a PDF (which in this case will be a packing slip since this is running on the Item Fulfillment transaction).

Now our Shipment Notifications are easily sent to our customers at the end of everyday.

As you can see this Send Email action is much more powerful and versatile than the email functionality built into Saved Searches and can provide a TON of communication to both your internal users AND your external Customers and Vendors.  One major gap in this action is the ability to choose different PDF templates when generating the attachment for this email.  Unfortunately, NetSuite only allows you to use the PDF template attached to the transaction form set on the record.  This can cause some headaches in that you either need to be constantly changing the Custom Form field on transactions to meet certain use cases, or struggle with a seriously customized PDF template to cover all use cases.

At MGBC we've created an easier way to manage this requirement.  We have created a custom workflow action the generates a PDF document of the current record using ANY PDF template that you have defined.  Then once you have generated that PDF document and stored it in a custom Document Type field on your record you can use it in the Attachment parameters in your Send email action.  This way you can create and store PDF files of your transaction in ANY PDF template with completely customized criteria, then send them to your Customers and Vendors using the native Send Email action as described above.

Checkout our custom Create and Attach PDF workflow action today.  OR email us at info@mgbcpro.com to learn more.

One of the nice things about these actions is that they are able to be executed from almost any client trigger and even a few server triggers.  Below is a list of triggers and how they interact with the record being affected by the workflow.  If you would like more information about how triggers work while working with records in NetSuite read our blog post on Workflow Triggers, Contexts and Event Types.

Now that we've gone through each trigger in detail we will go over which triggers are appliable to these three workflow actions
NOTE - These actions are not available for Scheduled triggers.

Now let's discuss what each action actually does.

• Set Field Display Type - this will change the way the field is displayed to the user while interacting with the record.  There are 4 options for this action:
• Normal - the field will be displayed normally in both View and Edit mode and there are no restrictions on Editing it
• Disabled - the field will be displayed normally in View mode, but in Edit mode the field will be "grayed" out and will not be able to be edited.  (NOTE - Disabled fields can still be updated by workflow actions)
• Inline - the field will be display as Inline HTML text in both View and Edit mode.  The user will not be able to edit or change the field value when the display type is Inline
• Hidden - the field will be hidden from the user in both View and Edit mode.
  
  
  
• ​Set Field Display Label - this will change the field name or label that is shown to the user in both View and Edit mode (depending on the trigger used).
  
  
• Set Field Mandatory - the field will be mandatory and cannot be left empty.  You can also toggle a field to be NOT mandatory as well.

The parameters of these actions are all very similar and managed pretty much the same.  The first step is to define the trigger to be used, or WHEN the action should be performed.  Then define any specific contexts or events that should trigger this action.  Lastly, define a condition that tells the workflow what criteria should be used to trigger the action.

In this example we want to make the the Class field mandatory when the Department is set to "200 Operations".  In this case we will use the After Field Edit trigger with the correct condition.  This way when someone edits the Department field the workflow will evaluate if the Department is "200 Operations" and if it is, trigger the action to make the Class field mandatory.
(Be sure to set the Triggering Client Field to Department as we want this action only to be triggered when someone updates the Department field)

Next we need to define the parameters of the action.  Here we will tell the workflow WHAT field needs to have the mandatory flag toggled and whether to turn ON the mandatory setting or turn OFF the mandatory setting.

(Leaving Mandatory checkbox unchecked will make the field NOT mandatory.  Leaving the Mandatory checkbox checked will make the field mandatory.)

As an added bonus you can toggle between Sublist and Body fields within these actions to change the field Display Type, Label and Mandatory setting for fields within the Items sublist on transactions, just like you can affect body fields.  

With this setup we can make the Job (or Project) field on each line when the Department of "200 Operations is selected

The Set Field Display Type has a few different parameters (described above) but functions similarly to the Set Field Mandatory Action.  Using the same After Field Edit trigger and Triggering Client Field of Department, but changing the condition to Department is NOT "200 Operations", the Class field will now be Hidden when the Department is changed and does not equal "200 Operations"

Lastly, we will change the Display Label of the Class field to "Financial Segment" when the Department is set to "900 Finance".  This way when someone selects the Finance department on a Transaction the Class field will be displayed as "Financial Segment" for more clarity to the financial user, but without having to add new custom fields to the record.

All these actions may seem small or "ticky-tacky" improvements to your system, but they can make a BIG difference when it comes to data consistency and accuracy.  Ensuring that users are always entering the correct information into the correct fields and NOT missing anything when required is a huge benefit to your NetSuite eco-system.  As the saying goes, "Garbage in, garbage out."  This will stop the garbage from even entering you system to keep it clean and maintained on an ongoing basis.