60% Faster HR Approvals with Make.com Conditional Logic: How Sarah Eliminated the Bottleneck

Multi-level HR approval workflows are where good processes go to die. A hiring request hits the wrong inbox. A budget exception waits three days for an approver who was supposed to be CC’d, not addressed. An offer letter routes to a department head when the salary threshold required CFO sign-off. These aren’t rare failures — they’re the default outcome when routing logic lives in someone’s head instead of a system.

This case study documents how Sarah, HR Director at a regional healthcare organization, used Make.com™ conditional logic to automate a four-tier approval chain, eliminate manual routing errors, and recover 6 hours per week that had been consumed by approval triage. For the broader strategic framework that informed this build, see the Make vs. Zapier for HR Automation: Deep Comparison.

Snapshot

Context and Baseline: A Four-Tier Process Running on Email

Sarah’s organization ran hiring approvals across four tiers depending on role level, department, and offer salary. A clinical staff hire at standard pay required department head sign-off only. A senior clinical hire above a salary threshold required department head, HR Director, CFO, and CEO approval — in sequence, not in parallel.

The problem: none of this logic existed anywhere except in Sarah’s mental model and a rarely-updated process document. Every new hiring request required her to manually read the requisition, determine the appropriate routing path, and email the right approver. If the requisition was incomplete or ambiguous, she’d spend additional time clarifying before routing could begin.

The downstream costs were measurable. According to SHRM, the average cost-per-hire exceeds $4,100, and a significant portion of that figure is driven by time-to-fill delays — delays that compound when approval routing is manual. Deloitte research on HR process efficiency identifies approval bottlenecks as one of the top three sources of hiring cycle drag. For Sarah’s team, the average time from requisition submission to final approval was 11 days. Industry benchmarks for streamlined organizations with comparable roles run closer to 4–5 days.

A second risk was financial. A misrouted approval — specifically, a requisition that bypassed the CFO tier for an above-threshold offer — had the potential to create the exact scenario documented in David’s case: an offer letter with an incorrect compensation figure that entered payroll unchecked. That type of error, where an ATS-to-HRIS transcription mistake caused a $103,000 offer to become a $130,000 payroll entry, illustrates the floor-level financial exposure when routing fails. The Parseur Manual Data Entry Report estimates that manual data handling costs organizations an average of $28,500 per employee per year when error-related rework and correction cycles are included.

Sarah needed conditional routing that ran itself — one that applied the same logic every time without requiring her to be the logic engine.

Approach: OpsMap™ Before Any Build

The first decision Sarah made — and the one that most determined the project’s success — was to run a structured process audit before touching Make.com™.

Using an OpsMap™ session, every approval scenario was documented: who approves, under what conditions, in what sequence, and what happens on rejection. This surfaced four edge cases that Sarah’s mental model had compressed into informal workarounds:

• Temp-to-perm conversions with salary increases above threshold required CFO approval even when the base role did not.
• Emergency backfill hires (vacancy created within 48 hours) bypassed standard department head routing and went directly to HR Director + CFO.
• Grant-funded positions required an additional approval from the grants administrator, regardless of salary level.
• Rehires of former employees within 12 months required HR Director review only, regardless of role level.

Each of these edge cases became a discrete Router branch in the Make.com™ scenario. Without the OpsMap™ discovery step, all four would have been silent failures — requests that either routed incorrectly or broke the automation entirely.

The Asana Anatomy of Work report found that knowledge workers spend a significant portion of their week on work about work — status updates, chasing approvals, and duplicating communication — rather than skilled work itself. Sarah’s 12 hours per week on approval triage was a textbook instance of this pattern.

Implementation: Building the Conditional Logic Scenario

The Make.com™ scenario was built in three phases over four weeks.

Phase 1 — Trigger and Data Capture

The scenario trigger was a Google Form submission linked to a Google Sheet. The form captured every data point required for routing decisions: role title, department, compensation offer, employment type, hire classification (new, backfill, rehire, temp-to-perm), and funding source. Every field was required — no submission could proceed with routing-relevant fields blank.

The form submission fired a webhook to Make.com™, which parsed all fields and made them available to downstream modules. This replaced Sarah’s manual intake step entirely.

Phase 2 — Router Architecture

The Router module sat immediately after the trigger. Seven branches were configured — one for each distinct routing path identified in the OpsMap™ session:

1. Standard hire, salary at or below threshold → Department Head only
2. Standard hire, salary above threshold → Department Head → CFO → CEO (sequential)
3. Temp-to-perm with salary increase above threshold → HR Director → CFO
4. Emergency backfill → HR Director → CFO (expedited, 24-hour SLA notification)
5. Grant-funded position (any salary) → Department Head → Grants Administrator → HR Director
6. Rehire within 12 months → HR Director only
7. Fallback branch → Sarah notified for manual review

Each branch used Make.com™ Filters with Boolean conditions matching the form fields. The fallback branch caught any submission that didn’t satisfy the conditions of branches 1–6 — a safety net that prevented uncaught edge cases from falling silently into a void.

For a deeper look at the technical mechanics behind advanced Make.com™ conditional logic and filters, including nested filter configurations, that satellite covers the build details comprehensively.

Phase 3 — Notification and Approval Action Modules

Each Router branch contained a sequenced set of modules:

• Approval notification email — sent to the first-tier approver with a summary of the requisition and two embedded links: Approve and Reject. Each link updated a designated cell in the tracking Google Sheet.
• Sheet status monitor — a Make.com™ watch module polled the sheet for status changes. When the first-tier approval was recorded, the scenario triggered the second-tier notification automatically.
• Rejection branch — a separate Filter condition on each tier’s output detected a rejection status and routed to a rejection notification module, which emailed the requester with the rejecting approver’s name and timestamp, and logged the outcome in the tracking sheet.
• Escalation module — a scheduled Make.com™ scenario ran every 24 hours and checked for any approval request older than 48 hours without a status update. It sent a follow-up to the pending approver and CC’d Sarah.

The entire chain — from form submission to final approval logged — required zero manual intervention from Sarah for the standard routing paths.

Results: Before and After

The 60% reduction in cycle time tracks directly to two changes: eliminating the delay between submission and first-tier notification (previously 4–24 hours depending on when Sarah processed the queue), and embedding approval action directly in the notification email so approvers didn’t need to log into a separate system.

McKinsey Global Institute research on process automation consistently identifies notification delay and context-switching overhead as the largest contributors to approval lag in knowledge-work environments. Removing both simultaneously produced compounding time savings that exceeded the initial projection.

Lessons Learned

What Worked

The fallback branch was used more than expected. In the first 30 days, roughly 8% of submissions routed to the fallback branch for manual review. Most were grant-funded positions where the funding source field had been completed ambiguously. This told Sarah two things: the form needed clearer field instructions, and her team’s process documentation had more gaps than the OpsMap™ session had surfaced. Both were fixable. Without the fallback branch, those 8% would have either broken the scenario or silently routed incorrectly.

Sequential approval chains require status polling, not webhooks. The initial build attempted to use webhook callbacks from email clicks to advance the chain. Approver email clients stripped or blocked certain link tracking parameters. Switching to a Google Sheet as the status ledger — with Make.com™ polling for changes — proved far more reliable. The sheet also became an unintended benefit: Sarah now had a real-time audit log of every approval, including timestamps and approver identity, without any additional reporting build.

Approvers needed one action, not a login. The embedded Approve/Reject links in the notification email were the single most impactful UX decision. Approvers who previously ignored approval requests because they required navigating to a separate portal responded within hours when the action was a single click from their inbox.

What We Would Do Differently

Build the rejection path first, not last. Rejection handling was treated as a secondary concern during the initial build and was added after the approval paths were complete. This created a two-week gap in the production scenario where rejected requests fell to the fallback branch rather than triggering the correct rejection notification. The lesson: rejection paths are equally critical to approval paths. They should be scoped and built in parallel.

Add a data validation module before the Router. Several early routing failures traced to malformed data in the form submission — a salary field with a comma in the number, a department name with a trailing space that didn’t match the Filter condition exactly. A data transformation module between the trigger and the Router — normalizing text fields, stripping whitespace, converting currency strings to integers — would have prevented all of them. This is now standard practice in every approval automation build.

Teams exploring how this architecture compares across HR process types will find the HR onboarding automation comparison and the candidate screening automation comparison useful frames for seeing where conditional logic delivers outsized returns versus where simpler linear automation is sufficient.

Verification: How to Know the Scenario Is Running Correctly

After deployment, Sarah’s verification protocol consisted of three checks:

1. Scenario execution history — Make.com™ logs every scenario run with module-level status. Any routing failure appears as a filter mismatch or module error in the log, identifiable within seconds.
2. Test submissions by tier — a set of synthetic form submissions covering each of the seven routing branches was run weekly for the first 30 days. Each test confirmed that the correct approver notification fired and the tracking sheet updated accurately.
3. Spot-check audit — once per month, Sarah pulled five completed approval records from the tracking sheet and verified that the routing path matched the requisition conditions. In 90 days of operation, no discrepancies were found.

Gartner research on process automation governance identifies execution logging and periodic spot-check audits as the two lowest-cost, highest-reliability verification methods for automated workflows. Make.com’s™ native execution history satisfies the logging requirement without additional tooling.

Closing: Conditional Logic Is Process Architecture, Not a Feature

The core lesson from Sarah’s build is not that Make.com™ is a capable automation platform — it is. The lesson is that conditional logic is a design discipline, not a configuration task. Every Router branch in the scenario represents a decision that previously lived in someone’s head. Making that decision explicit, testable, and auditable is what converts a manual approval process into a reliable system.

Teams that approach this as a software problem — “which tool should we use?” — miss the prior question: “have we fully documented every condition under which routing should change?” The OpsMap™ process answers that question before a single module is placed. The scenario then executes the answer, consistently, at whatever volume the organization requires.

For a side-by-side look at how Make.com’s™ visual scenario logic compares to linear automation at the architectural level — and why that distinction matters for complex HR processes specifically — the parent pillar provides the strategic framework this case study operates within.

Teams with sensitive approval data moving through automated scenarios should also review Make.com vs. Zapier security practices before deploying in a regulated environment like healthcare.