Oracle NetSuite's Workflow Builder (SuiteFlow) allows administrators to automate business processes without writing a single line of code. From approval routing to field validation to automated email notifications, workflows can handle a wide range of automation needs. This guide walks you through building your first workflow from scratch.
Understanding Workflow Components
Before diving in, it helps to understand the four core components of a NetSuite workflow:
- States – The stages a record moves through (e.g., "Pending Approval," "Approved," "Rejected")
- Transitions – The paths between states, triggered by conditions or user actions
- Actions – What happens at each state (set field values, send emails, create records, etc.)
- Conditions – The rules that determine when transitions and actions execute
Step 1: Create a New Workflow
Navigate to Customization > Workflow > Workflows > New. You'll need to specify:
- Name – A descriptive name (e.g., "Purchase Order Approval")
- Record Type – The type of record this workflow applies to (e.g., Purchase Order)
- Sub Types – Optionally restrict to specific subtypes
- Release Status – Keep as "Testing" while you build; change to "Released" when ready for production
- Trigger Type – Choose when the workflow initiates:
- Before Record Submit – Runs before the record is saved (good for validation)
- After Record Submit – Runs after the record is saved (good for notifications)
- Before User Edit – Runs when a user opens the record for editing
- Scheduled – Runs on a schedule against matching records
Step 2: Design Your States
In the workflow diagram, you'll see a default "State 1." Click on it to rename it (e.g., "Pending Approval"). Then add additional states by clicking the "Add State" button on the diagram toolbar.
For a purchase order approval workflow, you might create:
- Pending Approval – PO has been submitted and awaits review
- Approved – PO has been approved by the approver
- Rejected – PO has been rejected and sent back to the creator
Step 3: Add Transitions
Transitions connect states to each other. Click on a state, then click "Add Transition" to create a path to another state. Each transition needs:
- Target State – Where the record moves to
- Trigger Type – What initiates the transition (e.g., button click, field change, entry/exit of state)
- Condition – Optional conditions that must be met for the transition to occur
For our example:
- From "Pending Approval" → "Approved" (triggered by an Approve button)
- From "Pending Approval" → "Rejected" (triggered by a Reject button)
- From "Rejected" → "Pending Approval" (triggered by resubmission)
Step 4: Add Actions
Actions define what happens when a record enters a state, exits a state, or during a transition. Click on a state and use "Add Action" to configure. Common action types include:
| Action Type | What It Does |
|---|---|
| Set Field Value | Automatically set a field to a specific value |
| Set Field Mandatory | Make a field required at a specific state |
| Set Field Display | Show, hide, or disable fields based on state |
| Send Email | Send notification emails to users or groups |
| Create Record | Create a related record (e.g., a task for the approver) |
| Lock Record | Prevent editing of the record |
| Add Button | Add a custom button to the record form |
| Go to Record | Redirect the user to another page |
| Transform Record | Transform the record to another type |
For the "Pending Approval" state, you might:
- Add an "Approve" button and a "Reject" button
- Send an email to the approver notifying them of a pending PO
- Lock the record so the creator cannot edit it while it's pending
Step 5: Add Conditions
Conditions control when actions execute and when transitions trigger. You can base conditions on field values, user roles, or custom formulas. For example:
- Only trigger the approval workflow when the PO total exceeds $5,000
- Route to a different approver based on the PO amount range
- Skip approval entirely for POs under $500
Step 6: Test Your Workflow
Keep the workflow in "Testing" status while you verify it works correctly. In testing mode, the workflow only applies to your user (the administrator). Create test records and walk through each state to verify:
- Transitions trigger at the right time
- Actions execute correctly (emails sent, fields set, buttons appear)
- Conditions evaluate properly
Step 7: Release to Production
Once testing is complete, change the Release Status to "Released." The workflow will now apply to all users who meet the initiation conditions. You can also set an execution context to control whether the workflow runs in the UI, via SuiteScript, via CSV import, or via web services.
Best Practices
- Start simple – Build a minimal workflow first, test it, then add complexity incrementally
- Use meaningful state names – "State 1" is unclear; "Pending Manager Approval" is self-documenting
- Always test in Testing mode – Never release an untested workflow to production
- Document your workflows – Export the workflow diagram and document the business logic for future reference
- Consider the execution context – Decide whether the workflow should run for CSV imports, API calls, or only UI interactions
- Use conditions wisely – Over-complex conditions make workflows hard to debug. Keep logic clear and well-documented.
Next Steps
Once comfortable with basic workflows, explore approval routing workflows for multi-level approvals, or combine workflows with SuiteScript for scenarios that exceed the built-in action types.
Need help designing complex business process automation? Contact YRK Consulting for expert workflow development.