How to Build Approval Steps into Business Automations

A hypothetical purchasing workflow drafts an order, sends a message saying approved, and buys the item several minutes later. Meanwhile, someone edits the quantity. The approval now refers to a different proposal from the executed purchase. A useful approval step binds a named decision-maker to a specific version of an action, with clear limits and an expiry.

Define what the reviewer authorizes

Write the proposed effect in business terms: buy these items from this supplier for this total, or publish this exact document to this destination. Include fields that change the consequence. A generic approve workflow button hides important distinctions. A reviewer should understand the action without reconstructing several logs or trusting a conversational summary that may omit the material detail.

Give the proposal a stable identifier and version. Record the action payload or an immutable reference to it, the requester, the destination, and the relevant evidence. A hash can help detect changes, but a reviewer still needs a readable representation of the content. Cryptographic identity alone does not explain whether the proposal is appropriate. The approval interface must connect both representations reliably.

Separate requester, reviewer, and executor

Decide which roles may request, approve, and execute. For higher-consequence actions, separation can prevent one compromised identity from doing everything. A small business may need exceptions, but they should be explicit and recorded rather than hidden inside a shared account. Check whether the platform actually enforces the intended rule or merely displays an approval message before an unrestricted worker continues.

GitHub's deployment-review documentation provides a concrete approval mechanism for protected jobs, with availability depending on repository and plan. It is an example to inspect, not evidence that every automation product supports equivalent controls.

The executor should receive only the permission needed for the approved action. A reviewer saying yes to one invoice does not authorize editing supplier bank details or reading unrelated records. Review the connection's scope independently from the interface. If the worker has broad credentials, an approval screen may provide less protection than it appears to offer.

GitHub's secure-use reference discusses least-privilege workflow credentials. When using another platform, verify its equivalent permission controls rather than assuming the approval itself limits the underlying account.

Model approval as states, not a pause

Useful states include proposed, awaiting review, approved, rejected, expired, executing, completed, and uncertain outcome. Define allowed transitions. A rejected proposal should not become executable because a retry resumes after the pause. Expired approval should require a fresh decision. A changed material field should create a new version and invalidate the earlier authorization before the worker can act.

Persist the decision record before execution and prevent two workers from claiming the same approved action simultaneously. A timeout after an external write needs reconciliation, not another automatic purchase. Use the destination's idempotency mechanism where available. When its outcome cannot be determined safely, route it to investigation with the approved version and operation reference visible.

1. Create an identified, readable proposal.
2. Validate reviewer authority and separation rules.
3. Record approval for that exact version and validity window.
4. Recheck unchanged content immediately before execution.
5. Record the external outcome or investigate uncertainty.

A hypothetical order from proposal to execution

Order P-24 version 1 requests three replacement monitors from a known supplier. Its reviewer sees quantity, destination, total, and procurement reason. Before review completes, the requester changes the quantity to four. The workflow creates version 2 and marks version 1 superseded. Clicking an old notification cannot authorize version 2; the reviewer receives a fresh proposal with the material change visible.

After approval, the executor rechecks the version and validity window. The supplier API accepts the order but the response is lost. The workflow records uncertain rather than treating the timeout as rejection. An operator checks the supplier reference before deciding whether another submission is permitted. This invented example describes the required reasoning, not a tested integration or a guarantee that a particular vendor offers these controls.

Make review efficient without hiding evidence

Present the decision first, then the relevant details and supporting record. Show differences from a prior version when possible. Use clear approve and reject actions with a place for necessary explanation. Avoid making approval the easiest way to dismiss an alert. A queue should distinguish new requests from reminders and reveal how long a proposal remains valid.

Do not interpret silence as approval for a consequential action unless a genuinely authorized policy explicitly defines that behavior. An unattended queue is an operational issue. Provide an escalation route and a safe default when the reviewer is unavailable. For some tasks, that default is to keep a draft; for others, it may require a documented alternate reviewer.

Keep the review record independent of the notification channel. A chat message can be deleted, an email can be forwarded, and a displayed button can become stale. The system should validate the current proposal and reviewer identity at the moment of decision, then retain the result in the operational record used by the executor.

Approval-design checklist

• Name the exact effect being authorized.
• Bind the decision to a proposal identifier and version.
• Display material fields and differences clearly.
• Enforce reviewer authority and any separation requirement.
• Set an expiry and invalidate changed proposals.
• Prevent duplicate execution and reconcile timeouts.
• Restrict executor credentials to the required scope.
• Retain an accessible decision and outcome record.

Test old notification links, rejected proposals, duplicate approvals, edited payloads, and unavailable reviewers before enabling external effects. The purpose is not to collect a ceremonial yes. It is to make a specific action reviewable, authorized, and traceable through the outcome that actually occurred.