How to automate internal approval workflows

What this automation does

Every request follows the same path, the right people see it with everything they need, and nobody has to ask “did anyone approve this?” again.

1. Request. Staff submit through a form or a Slack or Teams shortcut. Each request type has its own fields, such as vendor, amount and cost center for purchases, or customer and discount percent for pricing exceptions.
2. Pre-check. Code confirms required fields and attachments are present. A model reads the justification and any attached quote, writes a three-line summary for the approver, and sends the request back to the requester if key information is missing.
3. Route. Rules decide the chain. For example, purchases under one threshold go to the manager, a middle band adds finance, and anything above that adds the owner. Some steps run in sequence, others in parallel.
4. Decide. Each approver gets a message with the summary, the amount, remaining budget where known, and buttons to approve, reject or ask a question. A rejection requires a reason.
5. Chase and escalate. Reminders go out after a set number of business hours. Requests that stay stuck move to a delegate or the next level up.
6. Act and record. Final approval triggers the next step, such as creating a purchase order, updating a record or notifying the requester, and every action lands in the audit log.

When it is worth building

Approvals are worth automating when you cannot answer “who approved this, and when?” without searching inboxes, when requests wait days because an approver missed a message, or when an auditor, grant funder or customer security review asks you to show a consistent process.

Check your existing tools first. Spend management platforms like Ramp and Brex include purchase approvals. HR systems handle time-off approvals, which we cover separately in the timesheet and PTO approvals guide. Microsoft 365 shops can get far with Power Automate’s approval actions. Build a custom workflow when approvals cross several systems, when the routing rules are specific to your business, or when you want one request log for every type of approval instead of five partial ones. Our n8n vs Power Automate comparison covers that choice in detail.

Architecture

How to build it

1. Write the approval matrix. List each request type, its thresholds and its approvers, and get the owner of each process (usually finance or HR) to sign off. Most delays in these projects come from unclear rules, not code.
2. Design one request schema. Shared fields for every type (requester, type, amount, status, version) plus type-specific fields. One table is far easier to report on than one per form.
3. Store routing as data. Each rule row says: request type, condition, approver role, order. A code step evaluates the rows. Avoid long chains of nested IF nodes that only one person understands.
4. Resolve approvers by role. Map roles like “department head” to real people from a directory table, synced from your HR system where possible, so org changes do not break routing.
5. Secure the decision. Map each Slack or Teams user ID to an employee record, block self-approval, and make email links single-use, identity-bound and time-limited.
6. Add reminders, delegates and escalation. Use a business-hours calendar so a request sent Friday evening does not escalate on Saturday morning.
7. Connect the downstream action. On final approval, perform the follow-on step and post the outcome back to the requester.
8. Pilot one request type. Start with the most frequent one, run it for two weeks, then add the others.

The downloadable starter template below gives you the request intake, rule-based routing and Slack approval steps to adapt.

What breaks in production

• Self-approval loops. When the requester is also the first approver, the chain must skip to the next level. Test this explicitly for every manager.
• Edits after approval. A request approved at one amount and then edited upward must restart approval. Store a hash of the approved content and compare it before acting.
• Stale approver mappings. People change roles or leave, and requests route to an empty inbox. Sync from your HR system and alert when a role has no active person.
• Lost waits. If the workflow holds state only in memory, a restart or upgrade drops pending approvals. Keep state in the request table and resume from it.
• Threshold splitting. A purchase above the limit split into several smaller requests to the same vendor. Flag multiple requests from one requester to one vendor in a short window.
• Rubber stamping. If approvers get dozens of low-value requests, they stop reading. Auto-approve by rule where the risk is small so attention goes to requests that need it.

Timeline and cost

One request type with chat approvals and an audit log typically takes one to two weeks. A full set of request types with delegation and downstream actions takes closer to three. Lumeor builds this in the range of $3,000 to $10,000, depending on how many request types and approval levels you have and which downstream systems the approved requests must update.

How to measure success

• Median hours from request to final decision, by request type
• Share of requests sent back for missing information
• Number of escalations, and which approvers trigger them
• Share of decisions with a complete audit record (the target is all of them)
• Split requests and self-approvals caught
• Requests approved in under ten seconds on high-value items, a signal of rubber stamping