Design an approval step for an AI-assisted workflow
An approval request needs to show the exact change someone is about to authorise. Include the target, the difference from the current version, the supporting evidence and what accepting will trigger.
Show the proposed change, not a reassuring summary
Imagine an assistant proposing to update a delivery promise on a product page. The approval card says “Improve product copy” and shows a green confirmation button. The reviewer cannot tell that the proposal changes “dispatch within three working days” to “delivery within three days”. The words are similar, but the customer promise has changed.
In this fictional example, the approval interface should show the existing sentence, the proposed sentence and the source supporting the change. It should also identify the exact product and destination. Approval becomes useful when the reviewer can see the consequential difference without opening several unrelated tools.
| Information on the approval card | Why the reviewer needs it |
|---|---|
| Exact target | Prevent approval for the wrong page or record |
| Current and proposed value | Expose what will actually change |
| Supporting source | Allow the new statement to be checked |
| Scope of the action | Distinguish a draft from a public update |
| Expected consequence | Explain who or what will be affected |
The table is a proposed interface design. It does not establish that any particular workflow product already implements these controls.
Treat approval as permission for a specific object
Suppose the reviewer approves the proposal, but a colleague edits the same page before execution. Applying the earlier proposal may overwrite the colleague's work or rely on a condition that no longer holds. The workflow needs a way to recognise that the approved object has changed.
Depending on the system, this can involve a record revision, a comparison of protected fields or another supported concurrency control. The implementation choice belongs to the target system. The editorial requirement is simpler: the action performed should still be the action the person reviewed.
A changed target should return for review when the difference affects the approved decision. Do not silently regenerate the proposal and reuse the old approval. The person approved a concrete change, not an unlimited series of future rewrites.
Design rejection and uncertainty before scaling
A reviewer should be able to reject the action, request a missing fact or send the proposal back for correction. Combining those outcomes into one “failed” state hides whether the issue is factual, procedural or technical.
The n8n error-handling documentation describes mechanisms for reacting to workflow failures. An approval rejection needs its own business meaning. It should not trigger the same automatic retry as a temporary technical failure, because the human decision may be precisely that the action must not occur.
After execution, the reviewer or operator needs a readable outcome: applied to the intended target, not applied, or awaiting verification. A timeout belongs in the last category until the destination is checked. Repeating a consequential action merely because its response was lost can produce a second change that nobody approved.
Start the pilot with these awkward cases. A workflow that handles one perfect approval demonstrates less about its control design than one that handles a rejection, a stale proposal and an uncertain execution result without losing their differences.
Define the decision package
Do not include unrelated personal data to make the request appear more complete. The CNIL's generative-AI guidance is a useful starting point for examining what information is supplied to such systems.
Verify the applied result
After execution, read back the relevant target fields and compare them with the approved proposal. A successful request submission is not enough to establish that the intended state was saved.
Keep a minimal decision record: proposed object, approver role, decision, application result and unresolved issue. Use the organisation's appropriate access and retention controls.
Test two cases before expanding: a rejected proposal and a proposal whose target changed while it waited. Neither should reach execution under an approval meant for a different object.
For the small-team AI use cases covered in our French guide, start with one reversible action and make its proposed change visible to the reviewer.
