An important concept about NetSuite workflows is that they are record-centric; they only exist in the context of the instance of a record. If you create a customer workflow that starts with new record instances, each created customer will have its own living workflow all for themselves. A customer's workflow will progress through its life cycle until it reaches the conditions that bring it to an end. This is both the strength and the limitation of NetSuite workflows. By being constrained to the instance of a record, a workflow is limited to the data of this small realm. There are ways around this limitation but it makes workflow development more involved. On the other hand, since the workflow lives with the record, it can monitor it continuously and take immediate action when the right conditions come together.
The first step in creating a workflow is to determine what will trigger its creation. A worklow can be created simultaneously with a record instance or every time the record instance is updated. Furthermore, we can define specific events and contexts that will trigger new workflow instances to be created. If I come back to my customer record example, I could have a workflow that comes to life alongside each new customer created in the NetSuite user interface. As the customer record's financial fields are edited, new workflows might be initiated. A customer updated through a CSV import might not trigger any workflows when the financial fields are changed.
The building blocks of a workflow are states and transitions. A state is a step in the workflow's life cycle where actions can be performed. A transition is the path that links two states together. In order to walk away from a state, a gate must be opened in order to grant access to another state. Specific conditions will be defined in order to open these gates. As a record instance is modified, gates will open and the workflow will follow its own path through the life cycle. A customer record where the credit limit has been increased to 100 000$ might be all that is required to open a transition form one state to another where new actions will be performed (email accounting department, set other fields on the customer record...) workflow life cycle complexity can vary greatly but you need to make sure that your record can flow through freely. It's easy to define a very complex network of transitions and find out that a record is locked in a state because no paths can be opened to other states. Workflows also provide continuity across all its building blocks with fields to store information. These fields can be local to states or global to the whole workflow.
|Anatomy of a Workflow|
Once a record instance lands in one of its workflow states, actions can be automatically performed. Ranging from sending emails to automating tasks, these actions are the tools that allow workflows to interact with the NetSuite world. Knowing what these actions are is key to understanding the possibilities of workflows:
- Add/remove buttons
- Create a records
- Subscribe to a record created from the workflow
- Lock the record
- Open another record
- Transform the current record into another record type
- Go to another NetSuite page
- Set a field value on the current record
- Set a field display mode on the current record
- Set a field's label on the current record
- Make a field mandatory or not on the current record
- Send emails
- Send marketing campaign emails
- Display a confirmation pop up dialogue
- Display a pop up message
- Display an error pop up
- Initiate another workflow
- And if these are not enough, it's always possible to execute a SuiteScript as an action
That being said, a workflow is unbeatable for any process that progresses alongside a record instance. The workflow will monitor the record instance and react as its being modified, possibly storing information about the changes and paths followed through the life cycle This provides a unique historical perspective of a record instance that is otherwise unavailable. Workflows are therefore the best choice for providing a life cycle flow on record instances. Developing the same level of functionality strictly with scripts would require elaborate triggering planing and custom records. Here are two examples to illustrate the differences:
- An record for a product item that needs to be engineered, submitted for approval, for which suppliers need to be approved, that must be released and that could eventually be deprecated would be a prime example of a workflow application.
- An order that requires automatic calculation of its line items' total weight following complex parameters and stored conversion factors should be developed with a script. We are acting at a specific time of the order's life and we are gathering data from a sub list and outside the realm of our record.
The NetSuite workflow beast does not eat SuiteScripts for breakfast. When tamed, Its rather gentle and it will be content with the province of your NetSuite kingdom you provide it with.