Approval work becomes a bottleneck when routine decisions depend on private messages and people cannot tell whether an action has actually been authorised. A manager may agree to a supplier purchase verbally; sales may promise an exception by email; finance may receive a request with no evidence of the agreed price. A small-business approval workflow should provide enough structure to protect consequential decisions while allowing staff to act freely inside their legitimate authority. This guide explains which requests are worth formalising, how to give an approver the necessary context and how to connect an approved decision to its actual operational result.
1. Identify decisions that really need approval
Start by listing common requests and their consequences. Examples include purchasing equipment, changing an agreed customer price, allowing an unusual refund, accepting a supplier variation, granting sensitive system access and approving a special project scope. Some may already be covered by clear employee authority. Do not create unnecessary management steps simply because workflow software makes it easy to insert an approval button.
For each case ask what could go wrong without a review, what evidence would reveal the problem and who has the legitimate authority to decide. Financial exposure is one factor, but privacy, service commitments, contractual change and security may be equally important. Write the rule in normal business language. If no one can explain why a manager must approve an ordinary low-risk action, revisit the policy before automating it.
Distinguish requesting advice from requesting authority. A colleague may ask an experienced employee how to handle an unusual customer without needing a formal approval record. Conversely, granting permission to spend or change contractual terms should leave clear evidence. A workflow should match the risk, not indiscriminately capture every conversation.
2. Design a useful request with only necessary fields
An approval task should contain the person asking, the decision type, relevant customer or supplier, intended action, reason, supporting source, value and currency where relevant, requested date and any important constraints. Different request types need different fields. A software-access request may need a system and role; a supplier purchase may require a quote and budget owner; a commercial concession may require the accepted contract reference.
Make required information explicit without demanding irrelevant details. A missing invoice number may be a legitimate reason to return a financial request for clarification; it should not force the employee to invent a placeholder. Link to authoritative records rather than duplicating confidential documents across multiple email threads. Ensure the approver can identify which version of a quotation or agreement is being considered.
Attach a stable request identifier to subsequent decisions and actions. If a staff member edits the amount or scope after approval, the system must determine whether the original authorisation remains valid. Significant amendments should require renewed approval rather than silently changing what was approved.
3. Route requests according to a maintained authority matrix
Approval routing should reflect who is authorised for the particular decision, not automatically use the highest-ranking person or whoever responded last. Set a manageable matrix by request category, financial band where applicable, business function and specific exceptions. Avoid embedding a complicated organisational chart in custom code when the routing can be maintained as controlled configuration.
Document role ownership and how changes are authorised. A manager's promotion, transfer or departure must not leave requests routed to an unavailable account. Some decisions require separation of responsibilities, such as a requester not approving their own payment. Where this matters, enforce the restriction in the workflow or receiving system rather than trusting a warning that can be dismissed.
In a small team, one person may legitimately hold several roles. That does not justify pretending a second independent review occurred. The audit record should show the actual decision maker and the authority exercised. Where independent approval is mandatory under a relevant policy, provide a genuine alternate route.
4. Provide approve, reject, return and withdraw outcomes
A simple yes-or-no interface can create confusion. An approver may be broadly comfortable with the request but need a missing quote, customer confirmation or security check. Use distinct outcomes: approved, rejected with reason, returned for information, withdrawn by requester and escalated for specialist review. Preserve who changed the status and when.
A returned request should keep its original identity and history while allowing a revised submission. If the material terms change, show the differences to the reviewer. Do not create an apparently new request just to erase a rejection or avoid a more senior approver. For a rejected item, make the reason intelligible enough that a colleague knows what must happen next, without exposing confidential deliberations unnecessarily.
When an employee withdraws a request because the underlying need has disappeared, cancel pending approvals and associated reminders. A rejected or withdrawn purchase should not later trigger an order through a delayed integration. This sounds elementary, but disconnected applications can create precisely that failure when they respond to a stale 'approved' event.
5. Plan absence, delegation and conflicts of interest
Approvals often become stuck during leave or illness. Define a delegate who holds the required authority for the appropriate period and category. Record who enabled delegation, the start and end dates and any limits. A temporary substitute should not acquire permanent permissions merely because somebody was away. Review outstanding approvals when the original approver returns.
Use escalation based on consequences and meaningful delay, not an endless stream of notifications. An overdue request may need a reminder, reassignment or conversation about whether the policy is practical. Escalation should not automatically override authority limits. If the only authorised person is unavailable, a genuine governance exception must be resolved by management rather than by appointing an arbitrary recipient.
Conflicts of interest matter for purchases, credits and supplier selections. Route requests away from employees who would improperly benefit from their own decision where relevant policy requires it. Retain only the evidence necessary to support the process and restrict access to potentially sensitive declarations.
6. Connect approval to the action being authorised
A decision is not the same as its execution. An approved purchase may need a supplier order; an approved account credit must be issued in the accounting system; approved sensitive access must be provisioned through the organisation's identity process. Decide which application owns the downstream event and who confirms successful completion. A workflow should not mark a request finished merely because the approver clicked the button.
Use a stable idempotency identifier so the same approval event cannot create two orders after a retry. Limit automated writes to specific operations that have been validated and authorised. Where the connector fails, retain a pending-execution state with an accountable owner. On reconnection, check the destination record before replaying the action.
Keep separation between an approver's business judgement and technical system permissions. A salesperson authorised to approve a small discount is not necessarily entitled to modify financial transaction history. The executing system should verify the permitted operation and relevant approval context, rather than blindly trusting a text message that says 'approved'.
7. Test security, privacy and audit evidence
Requests may contain contract prices, customer disputes, personal details or commercially sensitive supplier information. Restrict access by role and avoid copying full source documents into broad team notifications. Record the requester, original proposal, material revisions, decision, actual approver, relevant supporting references and downstream outcome. The record should be useful to someone investigating an error later, not just a database of checkbox events.
Test a requester trying to approve their own purchase, a revoked delegate, an amount changed after approval, a repeated webhook, a failed downstream connector and a person accessing another team's restricted request. Agree the correct outcome before running each case. Do not interpret a successful notification as evidence that permissions were enforced.
Automation tools can handle trigger, condition and approval actions, but plan entitlements and connector behaviour must be verified on the selected product. Microsoft's Power Automate approval documentation describes approval workflows; product capability does not replace a company's authority policy. Keep configuration changes controlled and preserve a manual emergency route for legitimate urgent cases.
8. Review the process and remove unnecessary friction
After a pilot, examine which requests are routinely approved unchanged, which are returned for missing details, which wait for unavailable people and which fail during execution. Repeated trivial approvals may mean the authority threshold is too strict. Repeated exceptions may reveal an unclear policy, weak source data or inadequate staffing. Do not measure success only by how quickly a manager clicks approval.
Ask whether a complete request arrives with useful context, whether decisions are consistent, whether employees understand the outcome and whether authorised actions actually happen. Include the cost of maintaining templates, permissions, integration and changes to staff roles. For very small volumes, a controlled shared register may be preferable to an elaborate multi-system workflow.
A practical approval system gives workers confidence to act inside clear boundaries. It does not turn management into an inbox bottleneck or give software authority it does not possess. Start with the consequential decisions, support them with reliable evidence and ensure every approved action can be traced to its real result. That is the foundation for accountable, efficient small-business decisions.
Recorded email approval or structured workflow: six verification steps
The deciding issue is whether the correct authority approved the unchanged request and whether the authorised action really happened. Compare both options on the same purchase or credit case before choosing software.
| Test | Recorded email sign-off | Structured approval workflow |
|---|---|---|
| 1. Request version | Reference the exact quote and original supporting record. | Lock or version the request before approval. |
| 2. Correct authority | Check signatory and permitted amount outside the email. | Use a maintained authority table with separation of roles. |
| 3. Clarification | Retain original thread and revised evidence. | Return-for-information state preserves the record history. |
| 4. Absence | Redirect only to a genuinely authorised delegate. | Apply time-limited delegation and log the actual decision maker. |
| 5. Real execution | Verify downstream order or adjustment separately. | Confirm receiving-system write and prevent duplicate retry. |
| 6. Exit and audit | Archive source, decision and resulting transaction. | Export linked history, routing configuration and final transaction evidence. |
Technical decision: use email at low volume if immutable evidence and accountable execution are maintained; use structured routing where repeated handovers, delegation and retries justify additional controls. Source A: Microsoft Outlook guidance provides email context, not proof of authorisation. Source B: Microsoft Power Automate approvals documentation describes structured approval functions. Neither product creates a company's authority policy or certifies a completed external transaction.
Frequently Asked Questions
Does clicking approve complete a supplier purchase?
No. It records a decision; the purchasing system must separately confirm that the authorised order was created once, with the correct version and amount.
What happens if a request changes after approval?
Preserve the original approval, compare revised material fields and route significant changes back to an authorised decision maker.
Can someone approve their own request?
Only where the applicable written policy truly grants that authority. Where independent review is required, the system must enforce it rather than assume a second person participated.
How should a failed connector be handled?
Record the failed or uncertain state, check whether the target transaction already exists and retry only with safeguards against duplication.