Direct answer: Automate onboarding approvals by building one Make.com scenario with a router that splits requests by department, sends each approver a webhook-triggered form instead of an email chain, and auto-escalates anything sitting untouched past a set time limit. IT and Facilities get their own branch, their own SLA clock, and their own audit trail. New hire records don’t move to “ready” until every branch reports back. No more chasing signatures across five inboxes. See our full onboarding automation guide for the complete framework this fits into.

Approval delays are the quiet killer of onboarding timelines. The paperwork gets automated, the welcome email goes out on schedule, and then everything stalls because IT hasn’t provisioned a laptop and Facilities hasn’t badged the new hire’s building access. Most HR teams built their onboarding automation around forms and notifications, then left approvals as a manual, email-based afterthought. That’s the gap this scenario closes.

This build assumes you already have new hire data flowing into a central system — if you haven’t connected your core systems yet, start with 8 systems to connect before automating onboarding. And if paperwork itself is still the bottleneck, fix that first with how to automate new hire paperwork.

Before You Start

You need three things ready before you build the router: a trigger event (new hire record created or status changed to “approved for onboarding”), a list of which departments require sign-off for which roles, and a webhook endpoint or form tool your approvers will actually use — Slack, Microsoft Teams, or a simple web form all work. If you haven’t built your first onboarding automation yet, back up to how to build your first onboarding automation in Make before tackling approvals specifically.

Map your approval chain on paper first. Write down every department that has to sign off before a new hire’s first day — usually IT (hardware, accounts, access), Facilities (badge, desk, parking), and sometimes Security or Compliance depending on the role. Each one needs a name attached: who gets the approval request, and who’s the backup if that person is out.

Step 1: Map Every Approval Point Before You Touch Make

Open a spreadsheet and list every role type your company hires for. Next to each, note which departments must approve before day one. A remote software engineer needs only IT. A warehouse hire needs IT, Facilities, and Security. This map becomes the logic your router runs on — skip it and you’ll be rebuilding the scenario every time a new role type surfaces.

This step also surfaces where your process is already broken. If nobody can tell you who approves Facilities requests for a satellite office, that’s a process gap no amount of automation fixes. Automation makes a clear process fast. It doesn’t invent a process that doesn’t exist.

Step 2: Build the Trigger and the Router

In Make, set your trigger to fire on the event that means “this hire is ready for department sign-off” — a status change in your ATS or HRIS, a new row in a tracking sheet, or a webhook from your paperwork automation. From there, drop in a Router module immediately after the trigger.

The router is what makes this scale. Instead of one long linear scenario that tries to handle every department in sequence, the router splits into parallel branches — one for IT, one for Facilities, one for any other approver you mapped in Step 1. Each branch runs independently, which means IT approving in ten minutes doesn’t wait on Facilities taking two days. Set a filter on each branch so only the relevant hires enter it — for example, only route to Security if the role tag matches your compliance list.

Step 3: Replace Email Approval Chains With a Webhook Form

Email approval chains fail for one simple reason: there’s no forcing function. A request sits in an inbox next to three hundred other unread messages and nobody knows it’s time-sensitive. Replace it with a webhook-triggered approval — Make sends the request to a lightweight form (Make’s own webhook response, a Teams adaptive card, or a Slack interactive message), the approver clicks Approve or Needs Info, and that response fires a webhook straight back into your scenario.

This isn’t just faster. It’s traceable. Every approval or rejection becomes a timestamped record in your scenario history instead of an email you have to dig up during an audit. If you’re not sure your systems are ready to support this handoff, review 8 systems to connect before automating onboarding to confirm your ATS or HRIS can expose the right trigger data.

Step 4: Set a Real SLA Clock on Each Branch

Every approval branch gets a timer. Use Make’s Sleep module or a scheduled re-check to measure how long a request has sat unanswered. Twenty-four hours with no response for IT, forty-eight for Facilities — whatever your internal standard is, build it into the scenario instead of hoping someone remembers to follow up.

This single step is usually the difference between an onboarding process that’s “automated” on paper and one that actually removes delay. A router without an SLA clock just moves the bottleneck from email to a dashboard nobody checks.

Step 5: Auto-Escalate When the Clock Runs Out

When the SLA timer expires without a response, the scenario should not sit and wait. Build an escalation branch: first notification goes to the original approver, a reminder fires at the SLA deadline, and a second escalation goes to that person’s manager or a designated backup if there’s still no response after a set window.

This is where a lot of HR teams get nervous about “automating too much.” You’re not removing the human decision — IT still decides what equipment ships, Facilities still decides badge access. You’re removing the chance that decision gets lost in a queue. That’s the adoption-by-design principle: the system fits into how IT and Facilities already work, it just makes sure nothing falls through.

Step 6: Aggregate Every Branch Before Marking the Hire Ready

Use an Aggregator module to collect the responses from every branch before the scenario marks the new hire as “fully approved.” This is the step teams skip, and it’s the one that causes the classic failure mode: a hire shows up on day one with laptop access approved but no badge, because nobody built a checkpoint that waits for all branches to report back.

Set the aggregator to require an explicit “approved” status from every mapped department before it updates the hire’s record and notifies HR the hire is ready. If any branch comes back “needs info” or “rejected,” route that back to the requester with the specific department’s note attached, not a generic “onboarding delayed” message.

Step 7: Connect the Approved Status to Day-One Checklists

Once every branch clears the aggregator, trigger whatever comes next in your onboarding sequence — welcome email, first-day schedule, manager notification. This is where the approval scenario hands off to your broader onboarding automation. If your day-one checklist process is still manual, close that loop with how to cut time to productivity with onboarding checklists.

The goal is one continuous scenario from “hire approved for onboarding” to “hire fully provisioned,” with approvals as a tracked, timed stage in the middle instead of a black box.

Step 8: Test With a Deliberately Slow Approver

Before this goes live, run a test where one approval branch is deliberately left untouched. Confirm the reminder fires at the right time, the escalation goes to the right backup person, and the aggregator correctly holds the hire in “pending” status rather than falsely marking them ready. This is the scenario that will happen in production — someone’s on vacation, someone missed a Slack notification — and it’s the one most teams forget to test.

How to Know It Worked

Track three numbers before and after: average days from “ready for approval” to “fully approved,” number of hires who reached day one with an incomplete approval (target zero), and number of manual follow-up messages HR sent chasing approvers (target near zero). Sarah, an HR Director at a regional healthcare system, reclaimed 12 hours a week after automating her onboarding workflow and cut total hiring time 60% — approval delays were a direct contributor to that time loss before the fix.

Common Mistakes

The most common mistake is building one long sequential scenario instead of a router with parallel branches. Sequential approvals mean Facilities can’t start until IT finishes, even when the two have nothing to do with each other. The second mistake is skipping the SLA clock on the assumption that people will check their Slack on their own — they won’t, consistently, and that’s exactly why the delay existed in the first place. The third mistake is aggregating without an explicit rejection path, so a “needs info” response gets treated the same as silence and the hire gets stuck with no clear next action for HR to take.

A fourth mistake worth naming: trying to solve this with an AI tool before the process itself is standardized. Our approach at 4Spot is automation first, then AI. A router with clear branches and a real SLA clock is the structure. AI can help draft the escalation message or summarize a rejection reason later, but it can’t replace the router doing the actual routing.

Related Reading

• 9 employee onboarding tasks you should never do manually in 2026
• 7 signs your onboarding process is costing you new hires
• 8 systems to connect before automating onboarding
• How to automate new hire paperwork
• How to build your first onboarding automation in Make
• How to cut time to productivity with onboarding checklists

Sources

• Make.com — Router module documentation
• SHRM — new hire onboarding checklist guidance
• Gartner — employee onboarding research
• McKinsey — people and organizational performance insights

Jeff Arnold is Founder and CEO of 4Spot Consulting, a Make.com Certified Partner.