If you have done much work with workflows in NetSuite you have probably seen the "Do Not Exit Workflow" checkbox on the header level of all states in your workflow. We get a lot of questions about this checkbox like; "When should it be used or avoided?" or "How does this checkbox effect performance in my environment?"
If you have had these same questions as well we will cover this one checkbox in depth in this article.
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.
Many people ask why would someone use this feature in a workflow. The most common use case here is within an approval workflow. If your approval workflow contains a Rejected state, then you may want to lock the record so it cannot be edited or changed again. In this scenario you would apply the Lock Record action in the Rejected state and then mark the Do Not Exit Workflow box so the record ALWAYS remains in the Rejected state and ALWAYS remains locked by the workflow. While this is a great use case for this function it is also useful when you have a single state workflow or a state within a workflow that you want the actions in that state to consistently be triggered every time the record is accessed. If you apply the Do Not Exit Workflow setting then the record will remain in the State indefinitely and all actions will continue to be triggered indefinitely. This helps to maintain consistency of the functions on your records while avoiding the need to re-create actions or copy actions into multiple states or multiple workflows.
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.