SuiteApprovals Approval Workflow States

When SuiteApprovals is set up, the workflow for routing approvals of supported record types runs in your system.

Approval validation starts when you create or resubmit a record through the NetSuite user interface.

Note:

Transaction records created using the following methods aren't routed for approval:

  • CSV import

  • Script

  • Web service

  • RESTlet

The record goes through the following states depending on the result of amount validation, approver validation, or approver actions:

Workflow State

Description

Entry

The record enters the Entry state when you create or resubmit the record. If there is no active rule found for the record, the record exits the SuiteApprovals workflow. If an active rule is found, the SuiteApprovals workflow initiates.

Pending Approval

Records that require initial or further approval are routed to the Pending Approval state. The following approvers receive an email notification about the record for review and action:

  • Current or next approver

  • Delegate approver (if any)

Only the current approver can approve or reject the record. The Approve or Reject buttons are only enabled for the current approver.

You can only edit rejected records. For more information, see the Rejected section in the SuiteApprovals Approval Workflow States help topic. To resubmit a record, see Resubmitting Records for Approval.

Approved

SuiteApprovals sets the record types to Approved based on the approval rules and the following conditions:

  • The transaction amount is less than or equal to the Record Amount Limit set in the approval rule.

  • The transaction amount is less than or equal to the employee’s entry limit for the following transactions:

    • Journal Entry

    • Expense Report

    • Purchase Order

    • Sales Order

    • Vendor Bill

  • The transaction is approved by the final supervisor (employee hierarchy), record approver, Final Approver, or the approver with the required approval limit (if skip approval is used).

  • The transaction is approved by all approvers (custom approval matrix).

  • For engineering change orders (ECOs), the ECO record is approved by the final supervisor (employee hierarchy) or Final Approver.

  • For requisitions, the record is approved for processing by the submitter’s supervisor, a specified approver, or all approvers.

For more information about additional conditions, see Automatic Approvals.

Note:

In approval rules that use a custom approval matrix with the same employee listed as the approver for two or more approver types, that employee's higher approval limit applies.

For example, Employee A is both Supervisor and Department Approver, the record is routed back to the employee as Department Approver after approving as Supervisor.

Rejected

Disapproved records are routed to the Rejected state. The submitter receives an email message, and the Approval Status on the record changes to Rejected.

Depending on the approval rule running against record types, records move to the Rejected state because of one of the following conditions:

  • The employee who submits the journal entry, purchase order, vendor bill, or sales order is the first or next approver in the chain.

  • For engineering change orders, the ECO record is rejected by the current approver based on the approval routing setting or Final Approver.

  • For requisitions, the record is rejected by the submitter’s supervisor or current approver.

  • The employee supervisor is selected in the approval chain, but the employee or submitter doesn't have a supervisor on record.

  • A department approver is selected in the approval chain but at least one of the following conditions is true:

    • There's no department approver set up, or the specified department approver is inactive or doesn't have login access.

    • There's no department specified on the journal.

  • There's no valid approver available. For example, if the approver type Role (Any) or Role (All) is selected in the approval chain, but at least one of the following conditions is true:

    • The employee or employees with the selected role are inactive.

    • The employee who created the journal entry is the only employee with the selected role.

    • The selected role is inactive.

    • No employee with the selected role has access to the transaction.

  • The approver type Group (Any) or Group (All) is selected in the approval chain, but the group has no valid members.

  • Invalid members include the employee who created the journal entry and employees who are inactive, without login access, or are from different subsidiaries.

  • The transaction is rejected by the current approver, Journal Entry Approver, Final Approver, or the approver with the required approval limit (if Skip approval is used).

  • No one in the approval hierarchy has sufficient approval limits to approve the transaction.

Resubmitted

You can edit and resubmit records with Rejected status for approval.

The Resubmit button is enabled when you view the record. Anyone with access can edit and resubmit the record for approval.

The Resubmit button is enabled when you view the record. Anyone with access can edit and resubmit it for approval. For more information, see Resubmitting Records for Approval.

For Engineering Change Order records, see Resubmitting Engineering Change Orders for Approval.

Cancelled

Cancelled sales order records automatically exit the workflow.

Effects of Enabled Features on the Approval Workflow

The following effects shows how the approval workflow can change when certain features are enabled:

  • Enabling the Email Approval feature doesn't change how approval validation works in the workflow stages. However, the SuiteApp may use email approval log rules to add extra validation for actions sent through email. The system lets an approver review email replies before the action is applied to the record. For more information, see Email Approvals.

  • In the SuiteApprovals workflow and workflow action scripts, the Execute As Admin property is enabled, which allows it to execute with administrator role privileges. This means approvers without the Override Period Restriction permission can approve vendor bills and post them in locked periods. For more information about this workflow property, see Execute As Admin.

    As a workaround for this issue, you can set up a script that detects vendor bills posted in a locked period and automatically moves it to the next open accounting period. For more information, see Resolve Vendor Bills Posted on Locked Period.

Related Topics

General Notices