Put an Approval Gate Where a Real Decision Happens

Workflow Design

An approval step adds value when it gives the right person enough information to make a specific decision. A vague approve button can simply move uncertainty downstream.

Name the decision precisely

“Approve the update” is ambiguous. “Approve this revised delivery date for communication to the project group” identifies a consequence. Include the current proposal, the reason for the change and the relevant source record. Keep the request short enough for a reviewer to understand without reconstructing the whole process.

Choose the decision owner

Use a role with authority over the decision, not whoever happens to own the flow. Define what happens if that person is unavailable. Microsoft’s Updates example connects a submission to an approval action; the organisational meaning of the approval still has to come from your process.

Keep rejection and silence distinct

A rejection is a decision. No response is a pending state. Design different routes for each. The next step might return the item for revision after rejection, while an overdue request goes to a coordinator for follow-up. Do not treat a timeout as implied approval unless that is an explicitly approved rule for this specific process.

Retain the decision record

Keep the request reference, outcome, decision time and any relevant comment with the work item. Test both approval and rejection using sample data. Check that downstream actions run only in the intended branch. A green flow status is not enough; inspect the actual record and the message or task created.

Decision requested: Approve the proposed schedule change
Context: Original date, proposed date, reason, affected work
Decision owner: [responsible role]
Approved: Record outcome, then notify the agreed audience
Rejected: Return to request owner with comments
No response: Remain pending and route for follow-up