Email is where approval workflows go to die.
A request comes in. Someone forwards it. Someone replies saying they'll look at it. Three days pass. The original requester sends a follow-up. The approver responds with a question. Another thread starts. Two weeks later, nobody can find the original request, the status is unknown, and someone has to reconstruct what happened from inbox search.
This isn't a people problem. It's a system problem - specifically, the absence of one. Email was never designed to track state. It doesn't know whether a request has been approved, denied, or abandoned. It doesn't remind anyone. It doesn't escalate. It just accumulates threads.
This guide covers how to replace email-based approvals with a structured workflow, what the components are, and how to build it with tools most small and midsize businesses already have.
What a structured approval workflow actually requires
Before looking at tools, be clear on what an approval workflow needs to do:
Capture the request in a structured format. The approver needs complete, consistently formatted information to make a decision. If every request looks different and arrives through a different channel, the review process itself becomes work.
Route the request to the right person. Not every request needs the same approver. Budget approvals above a threshold go to finance. Vendor contracts go to legal or a manager. Internal IT requests go to the IT team. The routing logic needs to be defined and automatic.
Notify the approver with enough context to act. The notification should include what was requested, who requested it, any relevant details, and a clear action the approver can take - without logging into another system to find the information.
Track status and escalate if nothing happens. A request shouldn't disappear into a queue without accountability. If an approver doesn't act within a defined window, the system should escalate or remind.
Notify the requester of the outcome. Once a decision is made, the person who submitted the request should hear about it automatically - with the result and any relevant context.
Email can theoretically do some of these things if you're disciplined about it. In practice, it does none of them reliably at any volume.
The building blocks
A practical approval workflow for a small or midsize business typically combines three components: a form for request capture, automation middleware for routing and notifications, and a CRM or task system for tracking status.
The form is the single entry point. Everything that goes through the approval process starts here. The form captures the request in a structured format - who is requesting, what they're requesting, any supporting details, and any fields that drive routing logic (request type, amount, department, priority level).
Using a form as the entry point, rather than email or Slack, accomplishes two things: it forces requests into a consistent format, and it creates a record that exists outside of any individual's inbox.
The automation layer watches for new submissions and handles routing, notification, and status tracking. Zapier, Make, or a custom webhook handler receives the form submission and executes the workflow logic: determine the appropriate approver based on request type or value, create a task or record in the tracking system, and send the approver a notification with the request details and an action link.
The tracking system is where requests live until they're resolved. This can be a CRM pipeline, a project management board, a dedicated approval tool, or a structured spreadsheet - depending on what the team already uses. The key requirement is that every request has a clear status (pending, approved, denied, escalated) and a clear owner.
Building the approval form
The form design step is where most approval workflows fail before they start. A form that captures too little information produces approvals without context. A form that captures too much creates friction and gets abandoned.
For the form to support the workflow, it needs to capture:
Requester identity. Name, email, department. This becomes the routing and notification address for the outcome.
Request type. A dropdown or multiple-choice field that categorizes the request. This is the field that drives routing logic - different request types go to different approvers.
Request details. The actual substance of the request. For budget requests, this is amount and purpose. For vendor approvals, this is vendor name, contract value, and scope. For internal requests, this is what's needed and why. Keep this structured where possible - specific fields rather than a single open text box - so the approver sees a consistent layout.
Supporting materials. A file upload field for attachments, contracts, quotes, or supporting documents.
Priority or urgency. Optional, but useful for routing high-priority requests to a faster approval path.
The form should include conditional logic so that fields relevant to specific request types appear only for those types. A budget approval form and a vendor contract form should look different - even if they're built on the same base form.
Routing logic: who approves what
Before building the automation, document the routing logic explicitly. This is the step teams most often skip, and skipping it is why automations break or produce incorrect routing.
A routing table might look like:
- Budget request under $500 → department manager
- Budget request $500–$5,000 → VP of Operations
- Budget request over $5,000 → CFO
- Vendor contract → Legal + VP of Operations (both must approve)
- IT access request → IT Manager
- Facilities request → Office Manager
Write this out before touching a tool. The automation is just executing rules you've already defined. If the rules aren't clear, the automation will route incorrectly and you'll spend time debugging logic rather than logic gaps.
Once the table is documented, translate it into the automation layer. In Zapier or Make, this typically looks like a series of conditional filters or path branches that check the request type field and amount fields, then route to the correct approver notification.
The approver notification
The notification the approver receives is the most important part of the workflow to get right. A notification that doesn't give the approver enough context to act forces them to go somewhere else to find the information - which is the behavior you're trying to eliminate.
A well-designed approver notification includes:
- Who submitted the request and when
- What was requested (the key details, not a link to go look them up)
- Any supporting context that affects the decision (amount, vendor, urgency)
- A direct link to any supporting materials
- A clear action: an approval link, a button, or explicit instructions for how to respond
The "approval link" pattern is worth implementing if you can. Rather than asking the approver to log into a system, the notification email includes two buttons: Approve and Deny. Each button triggers a webhook that updates the request status in your tracking system and fires the requester notification. Jotform's approval workflows support this natively. For custom setups, this requires a small webhook handler.
If an approval link isn't feasible, the minimum viable approach is a notification that includes all the request details inline, with clear instructions: "Reply to this email with Approved or Denied" or "Log into [system] and update the status of this request." The instructions have to be explicit - don't assume the approver knows what to do.
Status tracking and escalation
Once the request is submitted and the approver is notified, the workflow needs to track what happens.
The simplest tracking approach is a dedicated view in your CRM or a structured spreadsheet where every request has a row with status, approver, submission date, and resolution date. The automation creates the row on submission and updates it on approval or denial.
Escalation is the step most teams leave out and then regret. Define a time window for each request type - budget approvals should be resolved within 48 hours, vendor contracts within 5 business days. If nothing happens by the deadline, the automation should send a reminder to the approver and, if still unresolved, notify the approver's manager.
This is achievable in Zapier and Make using delay steps combined with a conditional check: after X hours, check whether the request status is still "pending" - if so, fire the escalation notification. In Make, this is more elegant because you can build it as a single scenario with a delay module and a router. In Zapier, it typically requires a separate Zap triggered on a schedule that checks for stale requests.
The requester notification
When a decision is made, the requester should hear about it automatically without anyone having to remember to send an email.
The outcome notification should include the decision (approved or denied), any conditions or notes from the approver, and the next steps if approved. For budget requests, next steps might include the purchase order process. For vendor contracts, next steps might include the contract execution timeline.
If the request is denied, the notification should explain why and what the requester's options are - not just "denied." A denial without context creates friction and follow-up.
A realistic implementation path
Week one: build the form and test it with five internal submissions. Focus on getting the request capture right - consistent format, appropriate fields, clean conditional logic.
Week two: build the routing automation and approver notifications. Test every routing path manually before going live.
Week three: add status tracking and the requester outcome notification. Set up basic escalation for overdue requests.
Week four: go live and monitor the first real submissions carefully. Most workflow issues surface in the first two weeks of real usage.
The full setup - form, routing, notifications, tracking, escalation - typically takes 15–25 hours of configuration work depending on the number of request types and the complexity of the routing logic. It's not a long project. The delay for most teams isn't the work itself; it's the time required to define the routing rules and get stakeholder alignment on the process before building it.
If your approval process is currently running over email and you want to see what a structured alternative would look like for your specific situation, a Workflow Review is the right starting point. We'll map your current process and show exactly what needs to be built. Request one here.
