Human approval in workflows: make authorisation meaningful

Identify the decision a person is making

Describe exactly what somebody decides. An employee may check that a file is complete without approving payment. A manager may accept expenditure without independently checking the supplier or bank account. Separate these decisions when they require different knowledge or authority. One button should not silently become responsible for every aspect of the business process simply because it is convenient to implement.

Also decide where human attention adds value. Routine field validation can often happen before review is requested. Do not ask a reviewer to spend time finding empty required fields that the workflow can recognise reliably. The person should focus on context, exceptions and consequences that fixed rules cannot adequately assess. This makes review more practical and reduces the temptation to approve every notification without meaningful inspection.

Present an understandable decision packet

Show the proposal, original information and significant uncertainties together. A purchase request might need the supplier, amount, purpose, desired date and evidence for any exception. Explain what the workflow has checked and what remains unverified. Confident wording or reassuring colours must not hide missing information that could materially affect the decision or the action that follows.

Make the origin of a suggestion visible. If AI proposes a description or classification, the reviewer should be able to inspect the relevant source. A summary may direct attention, but does not automatically replace the original material. Request a focused outcome: permission for this action, return for additional information or rejection with a reason that allows the person responsible for the request to take a useful next step.

Establish identity and authority

Receiving a link does not establish that the appropriate person made a decision. Determine how reviewers are recognised and which role is required for this instruction. Include absence cover and someone whose responsibilities change while a request remains open. The process should establish that the decision was made by an authorised person at the relevant time, rather than relying solely on the address that originally received a message.

Limit what a link or screen can do independently. A forwarded email should not silently confer the same authority as an authenticated organisation account. Design access according to the environment and consequences, and test unauthorised attempts. The technical mechanism follows from the selected systems. A workflow capable of waiting for a response does not automatically provide a complete authorisation design with suitable identity checks.

If an AI agent proposes the action, approval and technical permissions must fit together: Which permissions should an AI agent receive?.

Bind approval to the information version

Keep a record of the proposal that was reviewed. If the amount increases or the supplier changes, the instruction has changed. Decide which amendments need fresh approval and which administrative corrections do not alter the substance of the decision. State that boundary explicitly so that staff do not have to guess later which details were visible when somebody approved the earlier version.

Immediately before execution, check that the approved version remains current. A version number, modification time or another suitable comparison may support that check, depending on the source system. Test concurrent changes too: two people might open a request while a third modifies it. A screen that looked correct when opened is not proof that the final external action uses exactly the information the reviewer subsequently approved.

Give waiting and expiry their own routes

Decide how long an approval request remains valid and what happens when nobody responds. A reminder, reassignment or expired instruction may be appropriate. Choose according to the process instead of adopting an arbitrary platform default. An old request should not trigger a surprising action because somebody eventually opens a message after circumstances have changed or the work has been handled another way.

n8n provides ways to wait and resume processing. The business meaning still needs design: what may resume the workflow, what checks follow and when does the request become invalid? Do not treat missing response as permission. Name the person monitoring open approvals and explain how the organisation prevents work disappearing between a technical waiting queue and the ordinary list staff use to organise their daily responsibilities.

n8n: Wait ↗

Work through a fictional purchase request

A fictional company lets an employee prepare a purchasing request. The workflow collects the supplier, justification and amount and presents a proposal to the budget holder. That person can assess expenditure, while a separate check is required when payment details have changed. Approval applies to version three of the request and to the named supplier rather than to any later variation of the same record.

After approval, the requester discovers that a larger quantity is needed. The workflow marks the earlier approval as insufficient for the amended instruction and creates a new review request. The old link explains that it is no longer valid. This example shows that useful automation is not mainly about making approval faster: it is about preserving the meaning of a decision while the surrounding information changes.

Prevent duplicate execution after approval

A double click, repeated response or redelivered event should not create two external orders. Keep a stable reference and distinguish an approved action that is pending, executing or demonstrably completed. Check the destination when the outcome is uncertain. Disabling a button in one browser does not prevent every kind of duplicate event or a second attempt from another device.

Also test approval and rejection arriving close together. Agree which transition is still permitted and how a completed instruction is handled. A rejection cannot always undo an external action. Where correction or cancellation requires a separate process, document its authority and checks. This prevents the design from implying that every decision remains fully reversible regardless of how far the underlying work has progressed after the initial approval.

Test exceptions as real user tasks

Acceptance should include more than an authorised employee clicking approve. Use an unknown user, expired link, changed source data, repeated approval and unavailable destination. Show what staff see when an action may have happened but confirmation is missing. That uncertainty often matters most during recovery, because another attempt can create additional consequences if nobody first determines what the destination has already done.

Assess clarity as well as technical correctness. Can somebody understand the decision and outstanding work without extra explanation? How long does reviewing the evidence take? A perfectly recorded approval has limited value when the reviewer has no practical opportunity to make an informed decision. Adjust the packet, notifications and scope if the trial shows that review requires more attention than the team can consistently provide during normal operation.

Keep a useful decision history

Record the instruction reference, reviewed version, decision, authorised person and relevant time under the agreed retention policy. Distinguish the decision from later execution. Approval does not prove that an external action finished. A successful action likewise does not prove that the preceding decision was based on the correct information or that the person had the required authority at that moment.

Make the history answer later questions. Staff should be able to determine why work remained pending, which version was approved and whether a replacement request exists. This does not require copying every piece of content into every log. A focused, access-controlled history with clear references supports investigation without creating an unnecessary second collection of complete business files that then requires its own management and access arrangements.

Turn the explanation into a project decision

Record your assumptions, unknowns and acceptance checks in the matching tool. Use the service guides to discuss delivery and scope.

• n8n consulting ↗
• Business process automation ↗

Questions about this topic

Continue with a related question