Withdraw an in-flight review without leaving an old approval actionable. Define who can recall a submission, what happens to pending tasks, and what evidence must be reviewed again before work is released.
A requester submits a service proposal for approval, then notices that the delivery date and scope are wrong. Editing the form is not enough: two reviewers may still have the earlier version open, and an old approval link may still be usable.
An approval recall workflow withdraws a submission from an active review so the requester can correct it and submit again. The business request can remain alive while its old review is retired. This blueprint is a recommended operating design for operations teams before final authorization and execution—not a claim that every approval tool behaves this way.
Separate recall from rejection and cancellation
Use precise outcomes. Recall is initiated by the submitter or another explicitly authorized role to withdraw an in-flight submission. Rejection is a reviewer’s decision against that submission. Approver withdrawal removes an approver’s own consent where the system and policy permit it. Service cancellation ends the underlying demand for work.
These actions are not interchangeable. Oracle’s approval-withdrawal documentation, for example, distinguishes an approver withdrawing consent from a submitter recalling a request. Its rules apply to that product; use the distinction to clarify your own policy rather than assuming identical behavior elsewhere.
Start with the initial approval workflow: who decides, what evidence they need, and what approval releases. Then add recall as a separate route. Once final release or execution has occurred, route the issue to the appropriate change, cancellation or reversal process. A recall label must not pretend that completed work has been undone.
Make the submission—not just the request—the work object
Keep one stable business-request ID and identify each review submission separately. For example, request SR-204 can have submission 1 recalled and submission 2 under review. A decision must identify the submission and evidence it evaluated, not merely the current contents of an editable form.
Before enabling recall, define this minimum record:
- Request and submission identity: business-request ID, submission ID or revision, current review state and submission time.
- Review basis: scope, amount if relevant, dates, attachments and the rules used to select reviewers. Preserve the reviewed version or an equivalent controlled record.
- Recall instruction: actor, authority, reason, requested time and the exact submission being withdrawn.
- Task inventory: every pending approval, its owner, prior decisions, dependent release actions and current disposition.
- Recovery evidence: recall result, unresolved tasks, changed fields, new submission identity and the accepted owner of the next action.
The requester owns the correction. An approval operator owns task reconciliation. The process owner decides eligibility and resolves policy disputes. The downstream work owner confirms whether release has occurred. Give each role a named backup; a shared queue without an accountable person is not a recovery plan.
Use a lifecycle with evidence at every transition
The states below describe a submission lifecycle. They do not replace the business request’s delivery status. Set response targets by risk and operating hours; the labels alone do not define a deadline.
| State | Accountable owner | Exit condition and evidence |
|---|---|---|
| In review | Assigned approver | Decision or authorized recall request refers to the current submission. |
| Recall requested | Approval operator | Validate requester authority, submission identity and latest decision/release state. Record eligibility outcome. |
| Reconciling recall | Approval operator | Retire pending review tasks through supported controls; account for every task and confirm no unresolved release action. |
| Recalled | Requester | Operator has confirmed withdrawal. Requester receives correction reason, task disposition and permission to prepare a revision. |
| Ready to resubmit | Requester | Changed evidence is complete, comparison with the prior submission is available, and routing is recalculated. |
| New submission in review | Newly assigned approver | Receiver accepts the current evidence packet and task. Only a valid decision on this submission can proceed to release. |
| Held | Approval operator | A named policy or system owner resolves missing authority, conflicting state or an unknown outcome; resume only after evidence passes the failed check. |
A denied recall leaves the submission in its actual observed state, with a reason and next owner. It must not silently become Recalled. Likewise, Recall requested is not proof that pending decisions are disabled. If your system cannot block them during reconciliation, establish an authorized manual release gate and test the remaining exposure before using the process.
Zoho Creator’s approval guidance makes recall dependent on configuration and describes retained approval history. This illustrates why eligibility and task outcomes need checking in the chosen application, rather than being inferred from a button name.
Define two accepted handoffs
From requester to recall operator
Sender: requester. Ready to send: the affected submission and reason are identified. Context: request ID, submission ID, changed facts, known pending reviewers, urgency and any known downstream action. Receiver: approval operator. Acceptance: the operator confirms ownership, checks current state and records the next action and response target.
Missing information stays with a clarification owner. Do not let an incomplete recall disappear into the ordinary review queue. The operator must inspect current state again before acting; a screenshot from the requester may already be out of date.
From correction owner to new reviewers
Sender: requester after confirmed recall. Ready to send: required corrections and attachments are complete. Context: new submission identity, prior submission reference, what changed, why it changed, current decision criteria and deadlines. Receiver: the authorized reviewers selected for the revised request. Acceptance: their tasks reference the new submission and expose the evidence they must review.
Do not carry earlier consent forward by accident. The process owner may define a documented rule for reusing unaffected checks, but changed scope, value or risk must be assessed against the current authority rules. A prior “approved” response is historical evidence, not blanket permission for a different submission.
Test the failure paths before relying on recall
Run controlled tests with expected outcomes, actual outcomes and retained task IDs. These are acceptance requirements, not assertions about your software.
| Failure or conflict | Required response | Resume evidence |
|---|---|---|
| Approve and recall arrive together | Operator checks the authoritative decision and release record. Hold ambiguous outcomes; system owner investigates. Do not decide the winner from notification order. | One reconciled outcome and proof of whether any release occurred. |
| Reviewer opens an old link after recall | The old task must not authorize the revised submission. System owner tests task validity; operator controls release if the application cannot enforce the requirement. | Old task is clearly retired or otherwise prevented from releasing work, with test evidence. |
| Recall response times out | Keep the outcome unknown. Operator checks the same submission and task records before another instruction; do not create a replacement business request. | Confirmed original operation outcome, or a documented supported reconciliation. |
| Owner unavailable or access missing | Route to the named backup; access issues stay Held with a system-owner task. Do not grant wider decision authority informally. | Authorized owner accepts the task and can inspect the evidence. |
| Duplicate recall or conflicting correction | Link duplicate instructions to one recall. Process owner resolves incompatible proposed changes before resubmission. | One agreed correction scope and one controlling new submission. |
| Final approval or execution already occurred | Stop the ordinary recall path. Downstream owner checks actual actions and routes a linked change/cancellation case as appropriate. | Accepted owner and disposition under the separate process; no fictional rollback. |
Do not delete review tasks just to clear the queue. Salesforce’s guidance on unwanted Advanced Approval records explains how deleting approvals can leave users facing confusing old links, while recall provides a meaningful outcome. The exact mechanism is product-specific; the operating requirement is a clear, retained disposition for superseded tasks.
Walk through a changed-scope request
Illustrative scenario: an operations coordinator submits SR-204, submission 1, for a two-day service assignment. A manager approves at the first stage; a second reviewer is still pending. The requester discovers that the assignment needs three days and a different delivery date.
The requester asks to recall submission 1. The operator verifies that final release has not occurred, records the current decisions and retires the pending review through the application’s supported process. The operator confirms Recalled only after task disposition is known. The first manager’s decision remains part of submission 1’s history.
The requester prepares submission 2 with the changed duration and date. Routing is evaluated again because the revised request may need different authority. Reviewers receive the changed evidence and the prior-submission reference. An old link to submission 1 cannot be used as approval of submission 2. If that control fails in testing, the workflow is not ready for unattended release.
Measure correction without hiding waiting time
- Demand: recalled submissions divided by submitted reviews, grouped by recall reason. Count each submission once, not each duplicate instruction.
- Flow: time from recall request to confirmed recall, plus correction time to resubmission. Show unresolved items separately rather than dropping them from the measure.
- Queue health: oldest pending recall, held items by owner and tasks without an accepted owner.
- Reliability: stale-task action attempts, conflicting approve/recall outcomes and unknown-operation cases.
- Quality and capacity: repeated recalls, missing-evidence returns and operator/reviewer load. Pair arrival volume with completions before changing staffing.
- Outcome: revised submissions reaching a valid decision without release under superseded evidence. Sample the record, not just the status label.
Keep original request age alongside the new submission’s review age. Restarting a review should not make long-waiting business demand appear newly arrived. Use recall reasons to improve the specific intake or evidence check that failed; a high recall count alone does not prove poor requester behavior.
Where Workhint fits
The Workhint Workflow Engine describes role-routed approvals and required details, files or notes before work progresses. Those building blocks fit recall intake, eligibility review and correction readiness.
Workhint’s Workflow Automation Software page describes structured forms, process stages, role permissions and event-based notifications. These are relevant to connecting requesters, operators and reviewers in one process. Confirm native recall behavior, stale-link invalidation, simultaneous-action handling and submission-history controls in the configured system; the cited pages do not establish those detailed semantics.
Build This in Workhint
Configuration brief: “Design recall and resubmission for [approval type], before final release. Outcome: changed evidence receives a valid new decision without an old task releasing work. Define requester, approver, operator, process-owner, system-owner and downstream-owner roles with limited permissions. Collect request/submission IDs, reason, evidence version, pending tasks and release state. Model In review, Recall requested, Reconciling recall, Recalled, Ready to resubmit, New submission in review and Held. Require eligibility review, complete corrections and accepted reviewer handoffs. Assign reconciliation, correction and exception tasks; notify owners when recall is accepted, blocked, confirmed or resubmitted. Require retained actor/time/decision history and links between submissions; validate storage and audit-history behavior. Provide views for pending recalls, held conflicts, stale tasks and revised reviews, with the measures above. Test concurrent decisions and old links before enabling release; use a controlled manual gate where required behavior is not verified.”
Keep the approval audit trail connected to both submissions. A history that shows only the latest editable values cannot explain what the earlier reviewer actually saw.
FAQ
Does recalling an approval cancel the business request?
Not in this design. Recall retires the active review submission so it can be corrected. Cancelling the underlying work is a different decision with different completion evidence.
Can a requester recall after one reviewer has approved?
Only if the chosen system and policy permit it at that stage. Check the latest final-approval and release state, preserve prior decisions, and define which checks must run again. Do not assume every application permits partial-review recall.
Should the new submission reuse the old approval?
Not automatically. Link the prior decision as history. Reassess changed evidence and current authority; carry forward an unaffected check only under an explicit, tested policy.
What if the system cannot confirm whether recall succeeded?
Keep the submission Held with an accountable operator and next review time. Inspect the original task and release records before retrying. Unknown is not recalled, approved or safe to replace.
Leave a Reply