Salto for
NetSuite
Articles
SHARE
Sonny Spencer, BFP, ACA
November 6, 2023
12
min read
NetSuite workflows are a great utensil in any NetSuite Administrator’s toolkit. While NetSuite Developers also leverage workflows, one of the benefits of customizing NetSuite with workflows is that a user need not have significant SuiteScript knowledge to build complex business process flows.
As powerful as they are, they do have a number of limitations that can be overcome with SuiteScript. For example, the ability to execute record changes at the line level should be managed with SuiteScript as opposed to workflows.
In this blog post, we are going to explore some of the common mistakes made when working with NetSuite workflows so that you don’t make these mistakes the next time you plan to create or modify a NetSuite workflow.
With the ease of use that comes with NetSuite workflows, it is all too easy to jump in and start building new workflows as new business requirements are shared. The challenge is that once a workflow has been built it can be difficult to reconstruct if it fails to meet the business needs.
Avoid this situation altogether by taking the time to build out the end to end process flow in another application (or good old pen and paper). This can then be shared with the project stakeholders to seek buy-in before proceeding with the workflow build. In addition, the process flow built outside of NetSuite will serve as supporting documentation for future reference.
When designing your workflow, don’t just focus on the business requirements. Think about the checks and balances that need to be implemented in order for the workflow to execute as desired. In some cases, you may offer up functionality that wasn’t previously considered by your end users. An example of this could be a rejection process flow. End users may provide requirements for an approval process, but omit the process for handling rejections. This is where NetSuite Administrators and Developers can add (even more) value by offering a solution that already includes a rejection process baked in.
NetSuite workflows can complex quickly, especially as business processes evolve over time and require changes to existing workflow logic. As you make changes to workflow logic, always be evaluating ways to simplify the process. The larger the workflow, the difficult it is to maintain and troubleshoot issues should they arise.
Where this is unavoidable, think through how you can simplify the workflow structure, if not the workflow actions themselves. Perhaps you have 10+ actions executing within a single workflow state. Consider breaking these out into smaller steps within separate workflow states. This should make root cause analysis a little easier when investigating issues as you should be able to narrow down to a problematic workflow state (usually).
Further, ensure that you have descriptive workflow state names so that it is clear to someone reading the workflow what each step does. Elaborate on this within the “Description” fields on each workflow state.
By default, workflows, workflow actions and workflow transitions will execute for all “Contexts”. The NetSuite Field Help for workflow contexts provides a useful example as follows:
If you have a workflow based on the sales order record type, and you set the workflow initiation Context Type to Web Store, this means that only sales orders submitted through the Web Store will initiate the workflow. Sales orders submitted through the Web Services, CSV Import, or any other context will not initiate the workflow.
This is an important concept for a number of reasons. You do not want workflows to execute on records you did not intend, so set the appropriate context on the workflow itself. The same logic applies for specific workflow actions and transitions.
From a system performance perspective, if you had thousands of sales orders being processed via CSV Import and had ignored the workflow context, it would execute against all of those sales orders when it shouldn’t have, causing a significant system performance impact without any benefit. As important as contexts are, don’t just rely on them as criteria for executing the workflow. Make sure you have other references in place to ensure workflows only execute on the records you intend.
When you are building a NetSuite workflow it is important to have the “Enable Logging” feature turned on. Workflow logs will help investigate as you build and work through challenges. The logs will pinpoint the exact workflow state and action that is not executing as intended.
Once a workflow has been fully tested and deployed to Production from Sandbox (or Dev), you should consider disabling logging on the workflow. Logging, especially for more complex workflows, will have some impact on system performance. This can be easily measured with the use of NetSuite APM (NetSuite Performance Management).
You should only need to investigate workflow logs (after the workflow is deployed to Production) when something goes wrong. At that point, you can enable the workflow logs temporarily to allow for root cause analysis and issue resolution. Once resolved, the workflow logging can be disabled once again.
NetSuite workflows can be initiated based upon an event i.e. when a user creates or updates a specific record, or initiated based upon a schedule. When scheduled, workflows will trigger against records that meet the criteria of a saved search at the frequency designated.
It is important to remember that not all business processes should be executed as and when a user creates or updates specific records in the system. You will have use cases where the workflow actions do not need to execute immediately and can wait until later, perhaps every 30 minutes, or daily at a fixed time (typically during off-peak hours).
Before making this critical workflow design decision, work with your end users to understand the impact to their day to day when working with this particular record. They may prefer to have the workflow executed on a scheduled basis, especially if this results in improved system performance vs real time updates.
Event based workflows are powerful as they execute business logic real time as users interact with system records. This can become a challenge when these workflows execute on large volumes of records at any given time, common with records created or updated via a system integration into NetSuite.
For example, if you have an event based workflow executing on thousands of records as they are integrated into NetSuite you should expect to see an impact to system performance during that time as the workflow needs to execute on each and every record.
While NetSuite workflows are able to execute against large volumes of records, you should consider alternative solutions, such as SuiteScript to process the business logic against large volumes of transactions. An alternative would be for the business logic to be executed in the systems upstream of NetSuite (source system or integration middleware) and then pass into NetSuite without any logic applied.
For smaller record volumes, go ahead and build/execute your workflows. For larger volumes, consider all of your options before committing to build a workflow to accommodate the business logic to be processed.
A number of the mistakes we have discussed in this blog post so far have touched on system performance and this mistake is no exception.
For records that have several workflows executing against them at the same time, you should consider whether it is possible to consolidate the workflows to a single workflow or at least a smaller number of workflows. Why? Having multiple workflows executing on the same record type can lead to unexpected system behavior, such as workflow actions not performing the expected results due to a conflict with an action in a different workflow that is executing simultaneously.
While this is not common for a small number of workflows, if the number of workflows grows for a given record you can expect to see more frequent workflow discrepancies. Another reason to avoid multiple workflows is that it makes for more challenging issue investigation and resolution, as there are many more workflow logs to review.
Bottom line - avoid having a large number of workflows executing on a single record wherever possible. This will impact system performance for that record and potentially run into system errors. Double check how many workflows are executing on each record by referencing the “Scripted Records” page within your NetSuite environment.
Manual migration of NetSuite workflows between environments is time-consuming and prone to human errors; a challenge often faced by busy Administrators. NetSuite offers several out of the box solutions like SuiteBundler, Copy to Account, and SuiteCloud Development Framework (SDF) for migration support, each with its own merits and limitations. While SDF may cater to more tech savvy developers, some prefer user-friendly alternatives like SuiteBundler and Copy to Account to perform NetSuite workflow migrations. Users do need to take the time to work through any environment dependencies prior to completing the migration, else they run the risk of bringing over duplicate configuration into their Production environment.
Another automation solution to consider is Salto, a SuiteApp that empowers NetSuite Administrators and Developers with faster deployment of custom developments. Salto excels in environment comparison, discrepancy identification, record dependency confirmation, and easy version rollbacks, making it a valuable tool in time-sensitive situations where manual rollback is far from ideal.
For more information on these best practices, check out Salto’s blog posts that explore some of the things that NetSuite Developers and NetSuite Administrators should consider when working within the NetSuite ecosystem. By following these best practices, you can manage your NetSuite workflows efficiently and effectively.
The ability to create custom business workflows directly in the UI is one of the many attractive features that NetSuite offers to its customers. When implemented correctly, they can help to execute your business processes smoothly. When things are not running smoothly, you have the ability to drill down in the workflow execution logs to troubleshoot.
Before jumping into your next NetSuite workflow, make sure you have considered whether a workflow is the right technical solution, with reference to expected record volumes, system performance and whether record creation / updates need to occur real time.
Salto for
NetSuite
NetSuite
SHARE
Sonny Spencer, BFP, ACA
November 6, 2023
12
min read
NetSuite workflows are a great utensil in any NetSuite Administrator’s toolkit. While NetSuite Developers also leverage workflows, one of the benefits of customizing NetSuite with workflows is that a user need not have significant SuiteScript knowledge to build complex business process flows.
As powerful as they are, they do have a number of limitations that can be overcome with SuiteScript. For example, the ability to execute record changes at the line level should be managed with SuiteScript as opposed to workflows.
In this blog post, we are going to explore some of the common mistakes made when working with NetSuite workflows so that you don’t make these mistakes the next time you plan to create or modify a NetSuite workflow.
With the ease of use that comes with NetSuite workflows, it is all too easy to jump in and start building new workflows as new business requirements are shared. The challenge is that once a workflow has been built it can be difficult to reconstruct if it fails to meet the business needs.
Avoid this situation altogether by taking the time to build out the end to end process flow in another application (or good old pen and paper). This can then be shared with the project stakeholders to seek buy-in before proceeding with the workflow build. In addition, the process flow built outside of NetSuite will serve as supporting documentation for future reference.
When designing your workflow, don’t just focus on the business requirements. Think about the checks and balances that need to be implemented in order for the workflow to execute as desired. In some cases, you may offer up functionality that wasn’t previously considered by your end users. An example of this could be a rejection process flow. End users may provide requirements for an approval process, but omit the process for handling rejections. This is where NetSuite Administrators and Developers can add (even more) value by offering a solution that already includes a rejection process baked in.
NetSuite workflows can complex quickly, especially as business processes evolve over time and require changes to existing workflow logic. As you make changes to workflow logic, always be evaluating ways to simplify the process. The larger the workflow, the difficult it is to maintain and troubleshoot issues should they arise.
Where this is unavoidable, think through how you can simplify the workflow structure, if not the workflow actions themselves. Perhaps you have 10+ actions executing within a single workflow state. Consider breaking these out into smaller steps within separate workflow states. This should make root cause analysis a little easier when investigating issues as you should be able to narrow down to a problematic workflow state (usually).
Further, ensure that you have descriptive workflow state names so that it is clear to someone reading the workflow what each step does. Elaborate on this within the “Description” fields on each workflow state.
By default, workflows, workflow actions and workflow transitions will execute for all “Contexts”. The NetSuite Field Help for workflow contexts provides a useful example as follows:
If you have a workflow based on the sales order record type, and you set the workflow initiation Context Type to Web Store, this means that only sales orders submitted through the Web Store will initiate the workflow. Sales orders submitted through the Web Services, CSV Import, or any other context will not initiate the workflow.
This is an important concept for a number of reasons. You do not want workflows to execute on records you did not intend, so set the appropriate context on the workflow itself. The same logic applies for specific workflow actions and transitions.
From a system performance perspective, if you had thousands of sales orders being processed via CSV Import and had ignored the workflow context, it would execute against all of those sales orders when it shouldn’t have, causing a significant system performance impact without any benefit. As important as contexts are, don’t just rely on them as criteria for executing the workflow. Make sure you have other references in place to ensure workflows only execute on the records you intend.
When you are building a NetSuite workflow it is important to have the “Enable Logging” feature turned on. Workflow logs will help investigate as you build and work through challenges. The logs will pinpoint the exact workflow state and action that is not executing as intended.
Once a workflow has been fully tested and deployed to Production from Sandbox (or Dev), you should consider disabling logging on the workflow. Logging, especially for more complex workflows, will have some impact on system performance. This can be easily measured with the use of NetSuite APM (NetSuite Performance Management).
You should only need to investigate workflow logs (after the workflow is deployed to Production) when something goes wrong. At that point, you can enable the workflow logs temporarily to allow for root cause analysis and issue resolution. Once resolved, the workflow logging can be disabled once again.
NetSuite workflows can be initiated based upon an event i.e. when a user creates or updates a specific record, or initiated based upon a schedule. When scheduled, workflows will trigger against records that meet the criteria of a saved search at the frequency designated.
It is important to remember that not all business processes should be executed as and when a user creates or updates specific records in the system. You will have use cases where the workflow actions do not need to execute immediately and can wait until later, perhaps every 30 minutes, or daily at a fixed time (typically during off-peak hours).
Before making this critical workflow design decision, work with your end users to understand the impact to their day to day when working with this particular record. They may prefer to have the workflow executed on a scheduled basis, especially if this results in improved system performance vs real time updates.
Event based workflows are powerful as they execute business logic real time as users interact with system records. This can become a challenge when these workflows execute on large volumes of records at any given time, common with records created or updated via a system integration into NetSuite.
For example, if you have an event based workflow executing on thousands of records as they are integrated into NetSuite you should expect to see an impact to system performance during that time as the workflow needs to execute on each and every record.
While NetSuite workflows are able to execute against large volumes of records, you should consider alternative solutions, such as SuiteScript to process the business logic against large volumes of transactions. An alternative would be for the business logic to be executed in the systems upstream of NetSuite (source system or integration middleware) and then pass into NetSuite without any logic applied.
For smaller record volumes, go ahead and build/execute your workflows. For larger volumes, consider all of your options before committing to build a workflow to accommodate the business logic to be processed.
A number of the mistakes we have discussed in this blog post so far have touched on system performance and this mistake is no exception.
For records that have several workflows executing against them at the same time, you should consider whether it is possible to consolidate the workflows to a single workflow or at least a smaller number of workflows. Why? Having multiple workflows executing on the same record type can lead to unexpected system behavior, such as workflow actions not performing the expected results due to a conflict with an action in a different workflow that is executing simultaneously.
While this is not common for a small number of workflows, if the number of workflows grows for a given record you can expect to see more frequent workflow discrepancies. Another reason to avoid multiple workflows is that it makes for more challenging issue investigation and resolution, as there are many more workflow logs to review.
Bottom line - avoid having a large number of workflows executing on a single record wherever possible. This will impact system performance for that record and potentially run into system errors. Double check how many workflows are executing on each record by referencing the “Scripted Records” page within your NetSuite environment.
Manual migration of NetSuite workflows between environments is time-consuming and prone to human errors; a challenge often faced by busy Administrators. NetSuite offers several out of the box solutions like SuiteBundler, Copy to Account, and SuiteCloud Development Framework (SDF) for migration support, each with its own merits and limitations. While SDF may cater to more tech savvy developers, some prefer user-friendly alternatives like SuiteBundler and Copy to Account to perform NetSuite workflow migrations. Users do need to take the time to work through any environment dependencies prior to completing the migration, else they run the risk of bringing over duplicate configuration into their Production environment.
Another automation solution to consider is Salto, a SuiteApp that empowers NetSuite Administrators and Developers with faster deployment of custom developments. Salto excels in environment comparison, discrepancy identification, record dependency confirmation, and easy version rollbacks, making it a valuable tool in time-sensitive situations where manual rollback is far from ideal.
For more information on these best practices, check out Salto’s blog posts that explore some of the things that NetSuite Developers and NetSuite Administrators should consider when working within the NetSuite ecosystem. By following these best practices, you can manage your NetSuite workflows efficiently and effectively.
The ability to create custom business workflows directly in the UI is one of the many attractive features that NetSuite offers to its customers. When implemented correctly, they can help to execute your business processes smoothly. When things are not running smoothly, you have the ability to drill down in the workflow execution logs to troubleshoot.
Before jumping into your next NetSuite workflow, make sure you have considered whether a workflow is the right technical solution, with reference to expected record volumes, system performance and whether record creation / updates need to occur real time.