Do not begin with a notification tool. Define the decision, the people authorised to make it, the context they need, the thresholds and sequence, the exception and escalation routes, the permanent audit record and the safe manual fallback. Then test the complete process with realistic requests—including rejection, reassignment, delay and system failure—before relying on it in daily operations.
Put this guidance into practice
Explore our custom CRM and ERP development, software development, application launch, premium website development and business automation services. We scope the work around your existing tools, team and goals.
Start with the decision, not the approval screen
An approval workflow exists to control a business decision. Write that decision in plain language before selecting software: what is being authorised, what changes after approval, what risk the approval controls and what evidence a responsible approver must consider. A vague instruction such as ‘manager approval required’ is not enough to design a dependable process.
Map the request from the event that creates it to the final operational outcome. Include the person asking, the person affected by the decision, the systems updated afterwards and the team that handles questions or disputes. GOV.UK service-design guidance recommends looking at a service from beginning to end, front to back and across every channel; an internal approval deserves the same complete view.
Challenge approvals that exist only because they have always existed. Some requests need a recorded human decision. Others can follow a clear policy automatically, or can be reviewed later through exception reporting. Removing an unnecessary approval may reduce delay more safely than digitising it.
- Decision and business risk being controlled
- Event that creates the request
- Operational change caused by approval or rejection
- People affected before and after the decision
- Evidence that the approval is genuinely necessary
Define authority, thresholds and sequence
Name the role that can approve each class of request and the boundary of that authority. A purchase, discount or access request may need different approvers depending on value, department, sensitivity, location or customer commitment. Store role-based rules where practical instead of embedding a particular employee’s name throughout the automation.
Choose the decision model deliberately. Microsoft Power Automate distinguishes between first-response, everyone-must-approve, custom-response and sequential approvals. These patterns are not interchangeable. First-response can be fast but unsuitable where two independent controls are required; sequential approval can protect order but creates delay when the first approver is unavailable.
Write threshold examples and edge conditions that the team can verify. Decide whether the amount includes tax, which currency and exchange date apply, how split requests are treated and what happens exactly at a boundary. Rules that look precise in a flowchart can still produce inconsistent decisions when the underlying business definition is unclear.
- Approver role and delegated authority
- Value, risk or category thresholds
- One, all or sequential decision model
- Boundary and currency rules
- Temporary delegation and conflict-of-interest route
Give the approver enough context to decide
A fast approval is not useful if the approver must search across email, spreadsheets and messages to understand the request. Define the minimum decision packet: requester, purpose, amount or impact, customer or project, supporting evidence, policy reference, prior related decisions and the deadline. Present the most important facts first while keeping a link to the underlying record.
Do not collect information simply because a form can contain it. GOV.UK guidance emphasises helping users reach an outcome with as few unnecessary steps as possible. Every required field should either support the decision, the work after it or the audit record. Remove duplicate entry when a trustworthy system can provide the same information.
Make comments purposeful. An approval may require a reason only for rejection, an exception, or a decision above a risk threshold. When free-text is important, tell the approver what a useful explanation contains. A database full of ‘approved’, ‘okay’ and blank comments is technically complete but operationally weak.
- Compact decision summary
- Source record and supporting documents
- Policy or threshold applied
- Required reason for exceptions and rejection
- Clear deadline and consequence of delay
Design rejection, escalation and change as first-class routes
Real requests are rarely limited to approve or reject. An approver may need more information, a correction, a reduced amount, another specialist’s review or a reassignment. Define which responses are valid and what each one does. Microsoft’s approvals guidance supports custom responses and reassignment patterns because business decisions often require more than a binary button.
Decide when an unanswered request becomes overdue, who is reminded, when it is escalated and whether the original approver can still respond. Avoid sending repeated reminders without ownership; they add noise without moving the decision. The requester should always be able to see whether the item is awaiting review, returned for changes, escalated, approved, rejected or cancelled.
Treat changes after approval carefully. If the amount, scope, supplier, permission or attached evidence changes materially, determine whether the existing approval becomes invalid and a new decision is required. Preserve the earlier version and decision instead of silently editing the record that was approved.
- Return-for-information and correction path
- Reassignment and specialist-review rules
- Reminder and escalation timing
- Cancellation and duplicate-request handling
- Reapproval conditions after a material change
Protect access and preserve an audit-ready record
Test the workflow with each real role. Requesters should not be able to approve their own controlled request unless policy explicitly allows it. Approvers should see the information needed for their authority and no more. Administrators may configure the workflow without being entitled to make every business decision.
Keep a durable record of the request version, submitted evidence, rule or threshold, assigned approvers, responses, comments, timestamps, reassignment and final system action. NIST guidance for access management notes that recorded approvals are necessary for audit and that logs should be protected and retained long enough for operational or forensic investigation. Apply retention that matches the business and legal context rather than keeping everything indefinitely.
Plan for sensitive information in notifications. Email or chat should alert the approver and lead to a controlled record; it should not expose confidential attachments or personal data to recipients who no longer have access. Review exports, forwarding, shared mailboxes and mobile notification previews as part of the security design.
- No unintended self-approval
- Least-privilege view and action rights
- Immutable request and decision history
- Protected logs and appropriate retention
- Safe notification and attachment handling
Test the operating process and the failure path
Test more than a successful approval. Use realistic requests at, below and above thresholds; rejection; return for changes; reassignment; delegate absence; duplicate submission; changed evidence; expired requests and cancelled work. Confirm that every participant sees an understandable status and that downstream systems receive the correct result only once.
Exercise failure conditions deliberately. What happens when the approval service, identity provider, email channel or destination system is unavailable? The business needs a visible error, a named owner, a safe retry or reconciliation method and a controlled manual route. A request must not appear approved in one system while remaining pending or absent in another.
Pilot the workflow with a bounded group and review decision time, overdue rate, returned requests, exception volume, incorrect routing, support questions and work happening outside the system. Microsoft’s implementation guidance recommends tightly focused testing with defined approval criteria. Use the evidence to simplify the rules before wider rollout.
Digi Startup India can map and build an approval workflow around your real operating rules, integrations and exception paths. The goal is not to digitise a chain of emails; it is to create a decision process that people can understand, operate and verify.
- Normal, boundary and exception scenarios
- Duplicate and changed-request behaviour
- System outage, retry and reconciliation
- Manual fallback with named ownership
- Pilot measures and rollout decision
Further reading
- GOV.UK Service Manual: Designing good government services
- GOV.UK Service Manual: Learning about users and their needs
- Microsoft Learn: Get started with approvals
- Microsoft Learn: Create and test an approval workflow
- Microsoft Learn: Recommendations for implementing automation
- NIST IR 7966: Security of Interactive and Automated Access Management
Frequently asked questions
Which business approvals are good candidates for automation?+
Start with approvals that occur regularly, follow understandable rules, need consistent evidence and create measurable delay or rework. Avoid automating a poorly understood or frequently changing decision until the business has clarified the policy, authority and exception handling.
Should every approval have two approvers?+
No. The number and sequence should match the risk and control requirement. Low-risk requests may need one authorised response or policy-based automatic approval; higher-risk decisions may require independent or sequential review. Document why the chosen model is appropriate.
What should happen if an approver is unavailable?+
Define a time-limited delegate, reassignment or escalation route before launch. Preserve who was originally assigned, who acted, under which authority and when. Avoid sharing accounts or permanently granting broad approval access as a shortcut.
Can an approval workflow replace the underlying policy?+
No. Automation applies rules; it does not resolve unclear authority, thresholds, evidence or exceptions. Agree the policy first, then encode it in a way that can be tested, audited and changed deliberately.