Invalidate approval when a queued action’s material details change

Approve a concrete effect

An approval should identify what the system will do: the acting account, destination or resource, content and material cost or scope. A general instruction to use a tool is too vague to cover every later request. Save a reviewed action snapshot so a worker can compare the dispatch request with the user’s actual decision.

Lupin authentication establishes a credential and its permissions. The documentation separately requires authorization for the real account, recipient and content of an external action. Successful authentication therefore cannot fill a gap left when a user approved one draft but the queue now contains another.

Define material fields before building the button

List the fields that change the external effect. For a communication, recipients, sending identity, attachments and body can all matter. For resource allocation, project, runtime configuration and approved spending boundary may matter. Ignore purely presentational fields only when they cannot alter execution.

Use normalized structured data for comparison and version the approval policy. A display preview can omit fields or truncate long content. The saved snapshot should represent the exact dispatchable action, with private content stored through an appropriate protected mechanism rather than copied into a public audit log.

Invalidate on edits and environmental changes

If a material field changes after approval, return the action to review before dispatch. Do not silently copy the old approval identifier onto a new request. A changed account selection or recipient resolver can matter even when the visible text stays identical, so compare resolved execution fields as well as the user’s draft.

Consider time and context too. A very old approval may no longer describe the user’s intended deadline or account state. Define expiration and revalidation rules suited to the workflow. There is no generic Lupin permission flag that can decide those product-specific human intent questions for the application.

Preserve in-flight uncertainty

Once an approved action has been dispatched, editing it does not establish cancellation of the original. Keep the original immutable action and its operation identity while investigating its result. Create a successor review record for the correction, linked to the original so both effects remain visible.

If the earlier attempt has an unknown provider outcome, pause the replacement until reconciliation or an explicit informed decision resolves the risk. An approval check and an idempotency check protect different boundaries: one binds human intent, while the other helps prevent repeating the same accepted action.

Make the audit trail factual and small

Record the reviewer identity, approval time, action version, material field fingerprint and dispatch linkage. This is evidence that an approval occurred for a specified snapshot, not proof that the external action completed. Provider acceptance, delivery and completion remain separate facts with their own records.

Use local fixtures to edit one material field between review and dispatch and assert a return to review. Add a benign display change to confirm the application does not demand approval unnecessarily. Then test an already-dispatched edit: it should preserve the old operation and create a separate successor, rather than mutate history.

Sources & verification

Reviewed against the checked-in Lupin implementation and official reference documentation on 2026-11-05. Operational examples are illustrative; no live paid action, provider mutation or external message was executed.

• Lupin authentication and resource policy ↗Checked 2026-11-05
• Lupin error reference ↗Checked 2026-11-05

Prepared with AI assistance by Lupin editorial. How we research and maintain these guides.