Put human approval after the work needed to make an informed decision, but before the action that requires permission. A workflow can collect permitted information and prepare a proposed change first. It should not send the message, update the live record or make the commitment until the authorized person has approved that particular action.
The important boundary is not a box labelled approval in a diagram. It is the point where the actual workflow must wait. Define what the reviewer sees, what their decision permits and what happens when approval is missing or no longer matches the request.
Name the action that needs permission
Start with a precise sentence: this workflow may prepare an internal room-booking proposal, but only the bookings coordinator may authorize changing the shared room calendar. That is more useful than saying that a person should check things somewhere along the way.
Separate preparation from commitment. Reading an authorized request, checking required fields and assembling a proposed calendar entry can happen before the decision. Writing that entry to a calendar other people rely on is a different action. Preparation can itself have consequences, such as disclosing information to another service, so include only steps already permitted by your process.
If the whole sequence is still unclear, first map the actual manual workflow. Approval placement answers a narrower question: which specific action must wait for which decision?
Give the reviewer a proposal they can actually judge
An approval request should identify the proposed action, its destination and the details that matter to the decision. A subject such as Approve room request is insufficient if the reviewer cannot see the room, date and time that would be entered.
Keep the underlying request reachable through the team's existing authorized access. Where practical, show the reviewed version or a stable reference rather than relying on a document whose contents can change without the reviewer noticing. Do not copy confidential details into a wider notification channel to make the request convenient.
For the room example, a useful proposal would distinguish:
- The request reference and the exact proposed room and time.
- The calendar that would receive the entry.
- Any unresolved information that prevents a decision.
- The person authorized to approve it and the action their approval permits.
This is an original planning example, not a working integration. A clear request helps the reviewer understand the decision; it does not enforce that decision in software.
Check that requesting approval really blocks the action
A notification and a waiting step are not necessarily the same thing. In Power Automate, Microsoft distinguishes its approval actions: Create an approval does not block execution, whereas Start and wait for an approval waits for its criteria or a timeout. A separately created approval needs the appropriate waiting step to obtain its response.
That is a product-specific distinction, not a universal recipe. Have the maintainer inspect the actual action and branching rules in the tool you use. Sending a request should not be mistaken for receiving permission.
Also distinguish decision completed from approved. Microsoft's approval-type documentation includes cases where rejection completes the request. The next action therefore needs the correct outcome condition, not merely an indication that the approval step finished.
Make the non-approval paths explicit
Decide what each possible state means before relying on the workflow. The following is a proposed review standard for an ordinary internal process, not a claim about settings every platform supplies.
| Decision state | Required boundary |
|---|---|
| Approved proposal | Permit only the action and details covered by that approval, subject to the process's other checks. |
| Rejected proposal | Do not perform the proposed action; record the decision and the permitted next step. |
| No response or expired request | Keep the action unapproved and route the unresolved request to its responsible owner. |
| Proposal changed after review | Check whether the approval still applies; obtain a new decision for changed material details. |
In the fictional booking workflow, approval for the small meeting room on Tuesday should not silently authorize the main hall on Wednesday. Have the maintainer establish a supported way to connect the approved details with the action about to run. Do not assume a request identifier alone proves those details stayed unchanged. If that connection cannot be established, hold the affected action for review.
Approval also does not guarantee that a room remains available while someone considers the proposal. Define which conditions must be checked again before the change is made, and when a conflict requires another decision rather than an improvised substitution.
Test the boundary from both sides
Use authorized fictional requests and controlled destinations. Before approving anything, inspect whether the consequential action has already happened. Then check the intended approved outcome. Repeat with rejection, no response and a material change to the proposal using the tool's supported testing arrangements.
Write down the expected result before each test and inspect the actual destination afterward. An approval email arriving is one observation; the calendar remaining unchanged until the right decision is another. If only the notification was tested, leave the action boundary unverified.
Do not use a real booking, customer message or payment to manufacture a test. A pending request is not permission to repeat an uncertain action. If investigation becomes a recovery task, use the separately defined manual fallback procedure rather than treating an approval button as a recovery control.
Keep the decision attached to the action
A useful approval gate has a named decision-maker, a reviewable proposal and a verified stop before the action that needs permission. Keep rejection, silence and changed details visible. Approval should settle a particular decision, not become a general licence for the workflow to improvise.
For broader preparation, Preparing SOPs for Automation is a short checklist covering validation, human intervention, testing and review. It can help organize the surrounding procedure; it does not configure an approval gate or prove one works. Continue through Automation in AI & Technology.
