SuiteFlow Trigger Type: When Create/Update Workflows Start and Why - All - Runs on View

SuiteFlow Trigger Type controls when a create/update workflow starts and enters its entry state. Selecting create or update as the initiation event is not enough: administrators must also choose the record-processing point at which SuiteFlow begins.

TL;DR: For create/update workflows, select Before Record Load, Before Record Submit, After Record Submit, or - All - in the Trigger Type dropdown list. Use the most specific option possible. - All - can initiate on a record view because viewing executes Before Record Load; it is not limited to saving records.

Key takeaways

A create/update initiation event also requires a selection in the Trigger Type dropdown list.
Before Record Load initiates when a user clicks New or Edit, or views a record.
Before Record Submit starts after Save is clicked but before the database write; After Record Submit starts after the write.
- All - responds to any triggering event, including a record view.
Only server triggers can start workflows; client triggers cannot start workflows or execute transitions.

Do I need to select Trigger Type for create or update workflows?

Yes. When a workflow is configured to initiate on a create or update event, selecting that event is not sufficient by itself. You must also select an initiation trigger from the Trigger Type dropdown list. The selected trigger determines the record-processing point at which the workflow initiates and the record enters the entry state.

This separates two configuration decisions. The initiation event identifies the relevant record activity—creation or update—while Trigger Type identifies when SuiteFlow enters the workflow during that activity. Configuring actions and transitions inside a state is a later concern: initiation controls when the workflow starts, whereas state configuration controls what runs after the record enters a state.

The source identifies the Trigger Type dropdown but does not provide a navigation path for reaching it. Do not assume that selecting create or update, by itself, establishes the workflow's timing.

SuiteFlow Trigger Type options and entry-state timing

Each initiation trigger maps to a distinct point in NetSuite record processing. The practical question is whether the workflow must begin while the record is loading, immediately before it is written, or after the write is complete.

Trigger Type	When the workflow initiates	What this means
- All -	For any triggering event. For example, viewing a record initiates the workflow because Before Record Load executes when a record is viewed.	The workflow can initiate for any action on the record. Oracle recommends choosing a more specific trigger when possible.
Before Record Load	When you load a record by clicking New or Edit, or when you view the record. The record enters the entry state at that point.	This option includes record viewing as well as loading a record for creation or editing.
Before Record Submit	After you click Save and before NetSuite writes the record data to the database. The record enters the entry state at that point.	The workflow begins during submission, before the database write.
After Record Submit	After NetSuite writes the record data to the database. The record enters the entry state at that point.	The workflow begins after the record data has been written.

These choices establish the initial trigger context as well as the starting time. If the entry state contains actions or transitions configured for the trigger that brought the record into that state, SuiteFlow processes those elements according to its action-before-transition execution order.

Why does the - All - trigger start a workflow on record view?

- All - is broader than “all save events.” It initiates the workflow for any triggering event, and record loading is itself a triggering context. Viewing a record executes Before Record Load, so a workflow configured with - All - can enter its entry state even if the user merely opens the record and never clicks Edit or Save.

When reviewing a workflow that uses - All -, account for every record interaction named in the documented behavior:

Viewing a record
Clicking New
Clicking Edit
Clicking Save

This explains why an administrator may observe workflow initiation without finding a corresponding save operation. The workflow is responding to record load, not an unexpected database write. It also explains Oracle's recommendation to choose a more specific initiation trigger where possible. If a process should start only during submission, use a submit-based option rather than a setting that also covers loading and viewing.

Do not use - All - merely because the correct timing is uncertain. Its broad scope changes which user interactions can place records into the workflow, including record viewing.

How do you choose Before Record Load vs Before Record Submit vs After Record Submit?

Choose the option that matches the processing point at which the record must enter the workflow: while the form loads, after Save but before the database write, or after the write.

Before Record Load

Choose Before Record Load when initiation must occur as the record is loaded through New, Edit, or viewing the record. Because this trigger includes viewing, it is appropriate only when opening an existing record is intended to initiate the workflow as well as loading a form for creation or editing.

This timing also matters for interface changes. A form change made during Before Record Load can remain visible on the rendered form even when a transition moves the record to another state. Moving to another state therefore does not necessarily prevent a user-interface change made during record load from appearing.

Before Record Submit

Choose Before Record Submit when the workflow should begin after the user clicks Save but before NetSuite writes the record data to the database. This avoids initiating merely because a user opened the record. It places entry into the workflow inside submission and before persistence.

The distinction from Before Record Load is not create versus update. Both are initiation-timing choices for create/update workflows. The difference is whether opening the record is enough or whether the user must proceed to Save.

After Record Submit

Choose After Record Submit when initiation must occur after NetSuite writes the record data to the database. Like Before Record Submit, this is tied to submission rather than viewing. The difference is the database boundary: Before Record Submit occurs before the write, while After Record Submit occurs after it.

Do not treat the two submit options as interchangeable merely because both follow a click on Save.

What is the difference between server triggers and client triggers in SuiteFlow?

SuiteFlow triggers arise from events that occur while NetSuite processes a record. They can govern workflow initiation, action execution, or transitions between workflow states, but server and client triggers do not have the same capabilities.

Only server triggers can start workflows. Client triggers can run supported actions in response to user interaction, but client triggers do not execute transitions. The documented examples for save-related behavior are:

Use a client trigger when users should be alerted to change a field before submitting.
Use a server trigger when users should be notified after submitting.

Server triggers occur when a record is read from or written to the NetSuite database, or when a record enters or exits a workflow state. NetSuite classifies server triggers as record-based, workflow-based, or time-based. The Trigger Type options covered here are tied specifically to loading and submitting records.

For developer-controlled workflow topics, see N/workflow module members for workflow control and workflow trigger task management. These related topics do not change the rule that client triggers cannot initiate workflows or execute transitions.

How does trigger timing affect actions and transitions?

Initiation determines when the record enters the entry state. After entry, SuiteFlow processes state actions and transitions in a defined order. This distinction helps separate initiation behavior from behavior caused by actions or transitions configured inside the state.

The processing sequence is:

Entry actions execute the first time the record enters the state, followed by Entry transitions.
Actions configured for the trigger on which the record entered the state execute.
Where applicable, transitions configured for that same trigger are evaluated and executed.
If the record transitions to another state, Exit actions execute before it moves to the next state.

For the same server trigger, actions execute before transitions. The broader execution model maps record activity to trigger processing as follows:

Record action	Trigger activity described in the execution model
A user creates or opens a record	Entry actions run the first time the record enters the state, followed by Before Record Load actions. Entry transitions and Before Record Load transitions are then processed.
The record loads in the browser	Applicable client-trigger actions can execute. Client triggers do not execute transitions.
A user clicks Save	Before Record Submit actions and transitions execute, followed by After Record Submit actions and transitions.

This ordering matters when diagnosing a form change that remains visible after a transition. A Before Record Load action may alter the form before SuiteFlow evaluates and executes the transition. The subsequent state change does not necessarily remove the already-applied form change from the rendered page.

Best practice: choose the most specific initiation trigger

Use Before Record Load only when New, Edit, and record viewing are valid initiation points. Use Before Record Submit when initiation belongs after Save but before the database write. Use After Record Submit when the workflow must begin after that write. Reserve - All - for requirements that genuinely call for initiation on any triggering event.

A focused review should verify four things:

Confirm that both the create/update event and Trigger Type are selected.
List whether viewing, New, Edit, and Save should each be able to initiate the workflow.
Compare the required database boundary with Before Record Submit and After Record Submit.
Review the entry actions, trigger-specific actions, and transitions that will run after initiation.

Testing should reproduce each intended interaction rather than testing only Save. This is particularly important for - All - and Before Record Load, where a simple view can initiate processing. Include the workflow in business workflow testing in Release Preview, and use a Release Preview test plan for business workflows to cover create, open, edit, and save scenarios separately.

FAQ

Is selecting create or update enough to start a workflow?

No. A workflow configured to initiate on record creation or update also requires an initiation trigger in the Trigger Type dropdown list. That selection determines when the record enters the entry state.

Why does - All - initiate when I only view a record?

- All - responds to any triggering event. Viewing a record executes Before Record Load, so the view can initiate a workflow using - All - even when the user does not edit or save.

When should I use Before Record Load?

Use Before Record Load when the workflow must initiate as a record is loaded by clicking New or Edit, or by viewing the record. It includes all three interactions.

What is the difference between Before Record Submit and After Record Submit?

Before Record Submit initiates after Save is clicked but before NetSuite writes the record data to the database. After Record Submit initiates after NetSuite writes that data.

Can client triggers start workflows or execute transitions?

No. Only server triggers can start workflows. Client triggers can run supported actions in response to user interaction, but they cannot start workflows or execute transitions.