Design an approval step that means something

An approval step is useful when the person can understand the exact action and the system can ensure that the same action is performed. A button labeled Continue provides little protection if the recipient, attachment, or commitment can change after the click.

For a small-business AI workflow, begin with one reviewed action, such as sending an approved service-information reply. This article explains how to specify that approval without assuming any particular product already supports it. The result is a concrete design you can review with an implementer.

Make the proposal specific enough to judge

The review screen should answer ordinary questions. What will happen? Which account will do it? Who or what will be affected? What information will leave the business? Can the result be undone?

For a message, show the verified recipient and channel, the actual text, each attachment, and any quoted price or promise. For a record update, show the target record and the before-and-after values. For a purchase, an entirely different review is needed, including seller, total, recurring commitments, and relevant terms. Do not hide these differences behind a single generic approval label.

OWASP's transaction-authorization guidance emphasizes that people must be able to identify significant transaction details and that authorization should be enforced on the server. Applying those principles to reviewed AI actions means designing both an understandable screen and an execution check. OWASP guidance.

Write an approval record before building the button

For an initial design, specify a stored proposal with these fields:

• A unique proposal identifier and the business it belongs to
• The operation and the connected account that will perform it
• The resolved destination or target record
• The exact content, attachments, and relevant record version
• Any cost, commitment, or meaningful side effect
• The proposer, eligible reviewer, and expiry condition
• The decision, execution state, and eventual provider receipt

These fields are a recommended design, not a universal product schema. Ask your implementer to explain how the human-readable view is generated from the same authoritative record the execution step will use. Avoid a design where the screen displays a friendly summary while a separate, changeable payload controls the action.

Tie the decision to the reviewed version

Suppose a reviewer approves a service reply with one public brochure. Before execution, another workflow step adds an internal estimate as an attachment. The approved action has changed, even if the message body is identical.

A practical implementation can store a version or integrity digest for the approved proposal and compare it at execution. Any material change should require a new review. The approval should also expire when its context becomes stale, such as when a quoted offer is withdrawn or the destination record changes.

OWASP specifically recommends protecting transaction details from modification, checking authorization at execution, limiting authorization validity, and preventing replay. The appropriate time window depends on the workflow; this article does not prescribe a universal expiry. Approval integrity and lifecycle.

Identify who may approve

A signed-in person may have permission to read a proposal without permission to authorize it. Check business membership, role, and any action-specific requirement at the decision and execution stages. A reviewer leaving the company or losing access should not leave old approvals usable indefinitely.

The model should never manufacture its own authorization by writing that an action is approved. Likewise, a document or incoming message containing the word approved is evidence to inspect, not an authenticated decision from the designated reviewer.

For shared work, name a primary reviewer and a backup. Define what happens when neither is available. Holding the proposal visibly is often better than silently routing it to an unrelated administrator with broader access.

A fictional changed-recipient case

Willow Sample Repairs is a fictional shop designing appointment reminders. A coordinator reviews a reminder for a known test contact. Before sending, a sample contact update substitutes a different address. The proposed acceptance test requires the old approval to stop working and the revised recipient to appear in a new review.

The coordinator should not have to detect the change by memorizing the previous screen. Show what changed and why review is needed. Include attachments and appointment details in that comparison. Use invented appointments and a controlled test mailbox when demonstrating the behavior.

Treat approval and execution as separate events

After approval, the connector can still fail, access can be revoked, or the provider can accept the action without returning a response. Track these outcomes separately. Approved, submitted, completed, blocked, and uncertain are useful distinctions when their meanings are documented.

An uncertain send must not return to the start as a fresh action with a new approval and duplicate message. Keep its operation identity, investigate the provider's result, and follow the connector's documented retry rules. A person clicking again should see the existing attempt and its status.

The completion record should show the final target, time, and evidence of the result. Provider acceptance may be different from delivery or a recipient reading a message; label only what is known.

Test the review boundary

Before a pilot, demonstrate that:

1. The wrong reviewer cannot approve the action.
2. A changed recipient, attachment, or material field requires review again.
3. Expired, canceled, or already-used approvals cannot authorize another action.
4. Removed connector access blocks pending execution.
5. Concurrent clicks do not create separate actions.
6. A timeout produces an honest, reconcilable status.
7. The activity record connects the proposal, decision, and outcome.

Also watch a reviewer use the screen. If they cannot identify the recipient or consequence without opening several hidden panels, simplify the presentation before adding more automation.

Take one sample proposal and these test cases to an InstallAI planning discussion. They help define what meaningful review should look like for your workflow before any live action is enabled.