The quick answer
In the custom SuiteFlow shown here, inspect the Pending Approval state's Add Button rows. Approve and Reject both use the button-display condition Next Approver = User; this condition alone does not prove full authorization. Open the intended purchase order as its matching next approver, confirm Pending Approval, then click Reject. Verify that the same order's badge and Approval Status change to Rejected. Resubmit for Approval appears afterward; this walkthrough stops before using it.
Person, company, vendor and order names in these screenshots are fictional example data. Use the purchase order and authorized approver relevant to your work.
Before you start
These illustrations reconstruct a custom SuiteFlow approval example from a historical 2017.1 walkthrough in a current purchase-order form layout. The current form reference verified layout, not this custom workflow's behavior. Confirm your account's actual workflow and form; labels, conditions and controls can differ. Standard Approval Routing, SuiteApprovals and other custom workflows may use different procedures.
You need access to the workflow definition and the purchase order, plus permission to perform the intended rejection. A button's display condition is one part of the configuration; it is not the complete authorization rule.
The example order is PO61482, from Redwood Industrial Supply, for 1,307.10 in US Dollar. It starts in Pending Approval with Alex Morgan as Next Approver. Alex Morgan is also the user shown in the header. No user switch or comparison with another user's access is performed here.
01. Read the button condition
Open the existing Purchase Order Review workflow and inspect its Pending Approval state. In Actions, read the Add Button rows for Approve and Reject. Each Add Button action is configured with Trigger On: Before Record Load and shows Next Approver = User.
If inspection opens the state editor, choose Cancel when finished. This procedure reads the existing definition and makes no configuration changes. The predicate helps explain the buttons in this example; it does not establish that every missing-button problem has the same cause.
02. Check the matching approver
Use Global Search to open PO61482 Redwood Industrial Supply. Confirm the order number, vendor and total before acting.
Check the Pending Approval badge and Approval Status. Read Next Approver: Alex Morgan and compare it with the current user in the header. Approve and Reject are visible on this example order.
03. Reject and verify the result
Once you have confirmed the intended order and decision, click Reject once.
Wait for the record to update. Confirm that both the badge beside the order title and Approval Status read Rejected. Check that the order number, vendor and total still identify the same purchase order.
On this recorded order, Approve and Reject are no longer displayed and Resubmit for Approval is now visible. The retained Next Approver value does not mean the rejected order is still awaiting that user. Stop here: no rejection reason, correction or resubmission has been entered or verified.
Common questions
Does Next Approver = User cover every permission check?
No. It is the condition on these Add Button actions. Record access, role permissions, workflow state, other conditions, scripts and server-side validation may also affect the available action and its result.
Why might the creator and approver see different buttons on the same order?
A workflow can add buttons according to the current user and the record's Next Approver. Inspect the actual Add Button condition and current state before drawing a conclusion. This walkthrough checks the matching approver; it does not test another user's access or establish a universal missing-button diagnosis.
Did the rejected order automatically go back for approval?
No resubmission is demonstrated. The observed endpoint is Rejected with Resubmit for Approval visible. Any correction and resubmission is a separate action to verify in the account's workflow.
Does this prove anything about receiving, billing or payment?
No. This example verifies the recorded custom approval state and displayed controls. It does not verify a threshold rule, full transition configuration, audit history, edit permissions or downstream receiving, billing, payment and notification results.