After Record Submit Trigger

The After Record Submit trigger is a server trigger and executes after NetSuite saves the record data to the database. Actions and transitions set to execute on After Record Submit execute on the NetSuite server, after the record data is saved to the database.

Note:

In System Notes, NetSuite logs the role for the saved record as Administrator, even for non-Administrator users.

When an action executes on an After Record Submit trigger, NetSuite internally reloads the record, executes the action, and then saves the record again. NetSuite only saves the record again if the record has changed by the action.

The After Record Submit trigger can be used for the following elements of a workflow:

Workflow initiation. See Workflow Initiation Triggers and SuiteFlow Trigger Execution Model.
Actions. For a list of actions that support the After Record Submit trigger, see Workflow Triggers Quick Reference.
Transitions. See Transition Triggers.

The following diagram shows typical record events and when the After Record Submit trigger executes:

A diagram showing typical record events and when the After Record Submit trigger executes.

In general, use the After Record Submit trigger when you want to use a workflow to make changes to the record after NetSuite saves the data to the database. For example, use the After Record Submit trigger in the following situations:

A field or field value value is not available until after NetSuite saves the record.
Actions should occur after NetSuite saves the record. These actions can include the Send Email, Go To Page or Go To Record, or Create Record actions.
Record must transition to another state after NetSuite saves the record.
Some fields on the current record are set by NetSuite by other fields that are changed when the record is submitted.
You want to perform other actions on an After Record Submit trigger that require you do computation and then store the result in the current record.

After Record Submit Trigger Example

The following screenshot shows actions for a state set to execute on the Before User Submit and After Record Submit triggers. The actions on the After Record Submit trigger require specific field values to be present in the database to execute.

A screenshot that shows actions for a state set to execute on the Before User Submit and After Record Submit triggers. The actions on the After Record Submit trigger require specific field values to be present in the database to execute.

Trigger Type	Action Behavior
Before User Submit	Sets the Service Manager field on the record, which is required for one of the Send Email actions.
After Record Submit	NetSuite sends both emails after NetSuite saves the record data to the database. The first Send Email action requires the Customer information from the record. The required data is present in the database after the record save. The second Send Email action requires the Service Manager field value, which is set before the record save by the Set Field Value action.

Trigger Type

Action Behavior

Before User Submit

Sets the Service Manager field on the record, which is required for one of the Send Email actions.

After Record Submit

NetSuite sends both emails after NetSuite saves the record data to the database.

The first Send Email action requires the Customer information from the record. The required data is present in the database after the record save.

The second Send Email action requires the Service Manager field value, which is set before the record save by the Set Field Value action.

Comparing the Before Record Submit and After Record Submit Triggers

Although actions set to execute on the Before Record Submit and After Record Submit triggers both occur after the user clicks Save on a record, their use can affect edits made to the record.

The following table describes the differences between the two triggers for the Set Field Value, Custom, Create Record, Initiate Workflow, and Subscribe To Record actions:

Before Record Submit	After Record Submit	Other Considerations
All change made to the record by the workflow and the user are stored at the same time.	Any change made on the record by the workflow causes the record to be saved again when the workflow completes.	The Before Record Submit trigger results in better performance, for actions such as Set Field Value, as the record does not need to be potentially saved twice.
If the workflow execution fails for any reason, NetSuite cancels the entire operation. Any edit made by user is lost.	If the workflow execution fails for any reason, the data entered by the user has already been saved. The only changes that are not saved are those made by the actions that execute on the After Record Submit trigger.	Use the Before Record Submit trigger for any actions, such as Set Field Value, that depend on record consistency. Modifications to the record made on the After Record Submit trigger are rolled back in case of failure, which may leave the record in an inconsistent state. The inconsistency results from necessary record changes not being made.
Any business logic that executes when the record is stored has not executed yet, and can cause an inconsistent state of the record.	Any business logic that executes when the record is stored has already executed, resulting in a more consistent state for the record.	Typically, actions that use both trigger types modify the record but also may need to read the record, usually in an action condition. In this case, the After Record Submit trigger may be more effective.

Before Record Submit

After Record Submit

Other Considerations

All change made to the record by the workflow and the user are stored at the same time.

Any change made on the record by the workflow causes the record to be saved again when the workflow completes.

The Before Record Submit trigger results in better performance, for actions such as Set Field Value, as the record does not need to be potentially saved twice.

If the workflow execution fails for any reason, NetSuite cancels the entire operation. Any edit made by user is lost.

If the workflow execution fails for any reason, the data entered by the user has already been saved. The only changes that are not saved are those made by the actions that execute on the After Record Submit trigger.

Use the Before Record Submit trigger for any actions, such as Set Field Value, that depend on record consistency.

Modifications to the record made on the After Record Submit trigger are rolled back in case of failure, which may leave the record in an inconsistent state. The inconsistency results from necessary record changes not being made.

Any business logic that executes when the record is stored has not executed yet, and can cause an inconsistent state of the record.

Any business logic that executes when the record is stored has already executed, resulting in a more consistent state for the record.

Typically, actions that use both trigger types modify the record but also may need to read the record, usually in an action condition.

In this case, the After Record Submit trigger may be more effective.

Note:

Most other actions can use either of the above triggers, but not both.

After Record Submit Trigger Example

Comparing the Before Record Submit and After Record Submit Triggers

Related Topics