The quick answer
Not Running does not establish that an approval matrix is unused. In this historical 2020.1 SuiteApprovals example, a rule displayed Not Running and had an end date in the past. After one approver row was removed from the edit form, Save returned APPROVAL_WF_RECORD_USING. The message said the matrix could be updated only when it was not being used in any record.
The source ends at that error. It does not identify the referencing record, reopen the saved rule or demonstrate a recovery method.
Before you start
This walkthrough illustrates a historical failure path in a synthetic training configuration. Sales Order Approval Prior, Casey Reed, and the 10/01/2026–10/14/2026 dates are fictional substitutions. The illustration does not change a live account’s approval settings. Current forms, controls and SuiteApp versions can differ.
Use a prepared test rule with the existing matrix when following the illustration. This is an attempted change to an existing matrix, rather than new-rule setup or a tested migration procedure.
01. Match the existing rule
Open the edit form for Sales Order Approval Prior. Confirm Record Name: Sales Order and Status: Not Running. Read these as displayed values; they do not prove that no record still uses the matrix.
Read Start Date: 10/01/2026 and End Date: 10/14/2026. The illustrated dates mirror the source’s ended-rule situation; this exercise does not test date-boundary enforcement or change the dates.
02. Read the original matrix
In Approval Routing, inspect the existing custom chain. The first row is Specific Approver / Casey Reed; the next is Department Approver. Identify the intended row before editing.
The Delete column contains a row-level trash icon. This control is separate from the rule-level Delete action near Save. Enlarge the original frame to match Casey’s row and its rightmost trash icon.
03. Remove one row from the draft
Click the row-level trash icon for Specific Approver / Casey Reed only. The Department Approver row remains visible in the unsaved form. Leave the separate rule-level Delete action untouched.
The row’s disappearance is an edit-form observation. It does not establish that the saved matrix changed.
04. Read the Save error
Click Save. Read Notice (SuiteScript) and the code APPROVAL_WF_RECORD_USING. The message says it cannot save the approval-matrix changes and that an approval matrix can be updated only when it is not being used in any record.
Treat that as the system-stated reason for this attempted Save. The source does not inspect a referencing transaction or other record. It also does not reopen the rule, verify persistence, or show a successful deletion, replacement rule, reassignment or recovery.
Common questions
Why didn’t Not Running prove the matrix was unused?
The rule’s displayed status and the system’s matrix-usage condition are separate observations. This example showed Not Running, yet Save returned the in-use message.
Did the removed row save?
The evidence does not establish that. The row disappeared from the edit form before Save, but Save returned an error and the rule was not reopened to verify persistence. Do not infer a broader rollback result from these screens.
Which record was using the matrix?
The source does not identify it. The notice states a usage condition without naming a record or demonstrating the relationship.
Is removing a matrix row the same as deleting the approval rule?
No. This action targets one row in the matrix. Deleting the whole approval-rule record is a separate action and is not performed in this walkthrough.
What workaround does this example demonstrate?
None. It ends at the error. Copying, migrating, replacing or rebuilding the rule is not shown as a tested solution.