I85PREP
⌘ K
NetSuite SuiteFoundation study materials
NetSuite SuiteFoundation study resources

The Approval That Never Fired

NetSuite SuiteFoundation · Put your knowledge to work in context.

All case studies

The Approval That Never Fired

A company configured a SuiteFlow workflow to route Purchase Orders over $25,000 to the CFO for approval. The workflow is set to trigger On Create, with a condition of Amount is greater than 25000. In testing, POs of $30,000 were created and saved without any approval request. The PO form shows Amount populated, but the field is a custom currency field (custbody_po_total) that mirrors the native Amount via a client script. The workflow's condition references the native Amount field. The CFO approval step is configured with a recipient of a specific employee record.

1. Why did the workflow not fire, and what should be changed?

Read the worked answer

Two likely faults, address both:

  1. Timing/field population. The workflow triggers On Create and evaluates the native Amount. If the native Amount is populated by a client script after save (or is blank at create), the condition evaluates against an empty/zero value and fails. Change the trigger to After Submit (or On Create and After Submit) so the field is populated, or evaluate the custom field custbody_po_total that actually holds the value.

  2. Condition field mismatch. The condition references native Amount while the real value lives in custbody_po_total. Point the condition at the field that is reliably populated at trigger time.

Recommended: trigger After Submit, condition on custbody_po_total > 25000, and confirm the field is stored (not display-only).

2. After fixing the trigger, approvals fire but the CFO never receives them. What checks apply?

Read the worked answer

Check in this order:

  1. Recipient validity - the workflow step targets a specific employee record; confirm that employee has an active user with a valid email and that the record is not inactive.
  2. Workflow state - confirm the workflow is Released (not Testing/Not Running) and that the instance actually reached the approval state.
  3. Permissions - the recipient must have permission to approve the PO; otherwise the approval action may be blocked.
  4. Email/notification settings - confirm the approval action is configured to send a notification and that the account's email is functioning.

A common trap: the workflow is still in Testing state, so it runs for the admin but not for real users.