How to integrate Ashby with Rippling for clean hires

Most Ashby setups stop the moment an offer is accepted. The candidate clicks accept, someone in talent ops gets a Slack ping, and then a person opens Rippling, types the new hire's details by hand, picks a start date, assigns a workflow, and hopes nothing got missed.

That gap between offer accepted and onboarded is where most of the manual work in modern recruiting actually lives. Ashby is brilliant at the funnel. Rippling is brilliant at IT, payroll, and onboarding. The integration that connects them is almost always under-built, and the cost shows up everywhere: late laptops, missing access, drifted org charts, hiring managers who keep asking the recruiter for status.

This piece walks through what a clean Ashby to Rippling integration actually looks like, where teams trip themselves up, and the automations we build on top of it. The pattern applies to HiBob, Workday, and Deel as well. Rippling is just the most common pairing we see at Series B to D.

The Handoff Problem Most Ashby Customers Have

Symptoms we see when an Ashby and HRIS combo has not been properly wired together:

• Talent ops keeps a Notion or Google Sheet of accepted offers because the system of record is unclear.
• New hires show up on day one without a laptop, a Slack account, or access to the right tools, because IT only heard about them yesterday.
• Department, level, and manager fields differ between Ashby and the HRIS, so reports drift and someone has to reconcile them quarterly.
• Hiring managers cannot see in one place whether a hire is closed, signed, started, or still pending. They keep asking the recruiter.
• Cost-per-hire and time-to-productive cannot be calculated cleanly because the two systems do not share an identifier.

These are the symptoms. The cause is almost always the same: the native integration covers basic fields but not the workflow. The Rippling connector that ships out of the box will push name, email, and start date. It does not provision access. It does not negotiate the field-mapping fights between recruiting and HR. It does not tell the hiring manager anything. Everything past the basic sync is work.

Automation Plays We Build with Ashby

1. Offer accepted to fully provisioned in under 24 hours

Trigger: candidate moves to Hired in Ashby, or the offer signed webhook fires from Docusign. Workflow: a webhook hits n8n, the candidate record is mapped to the right HRIS schema (department, level, manager, employment type, location, start date, work eligibility), and a new hire is created in Rippling with the right onboarding workflow attached. Slack, Google Workspace, GitHub, 1Password, and Notion provisioning kicks off automatically based on the role's access template. A hold flag delays actual account creation until two business days before the agreed start date, so a delayed start does not mean a paid-for laptop sitting idle. Outcome: the new hire's environment is ready the moment they walk in, not the morning after.

2. Single source of truth on department, level, and manager

Trigger: any change to department, manager, or level in Ashby or Rippling. Workflow: a reconciliation script confirms both systems match against a canonical org chart stored in a small Supabase table, flags conflicts in a private Slack channel, and writes the canonical value back to both. The canonical table is owned by People Ops, with edits requiring a two-person review. Outcome: hiring analytics in Ashby and headcount reports in Rippling agree, every time. No more quarterly cleanup, no more headcount-vs-pipeline mismatches in the board deck.

3. Hiring manager status view without a new tool

Trigger: stage change on any candidate against an open req where the hiring manager is involved. Workflow: a private Slack channel per req gets a structured update on every stage move, scorecard submitted, debrief scheduled, offer sent, and offer accepted. Each post links to the Ashby candidate page and, after hire, the Rippling profile. Outcome: hiring managers stop asking recruiters for updates. The recruiter gets two hours of their week back per active req, and the hiring manager actually feels in control.

4. Cost-per-hire and time-to-productive that finance trusts

Trigger: nightly sync. Workflow: Ashby funnel data, Rippling start dates and salary data, and finance-side cost data (agency invoices, ad spend, tool seats, referral bonuses) get joined on a common hire ID and pushed to a Looker or Metabase dashboard. Time-to-productive is measured by milestone (first PR merged, first deal closed, first ticket resolved) pulled from the relevant tool. Outcome: a head of talent walks into a board meeting with one number per role family, not three different answers depending on who asked.

How Ashby Should Integrate With Your Stack

A clean Ashby integration footprint for a Series B to D tech company usually looks like this:

• HRIS: Rippling, HiBob, or Workday. Two-way sync on the canonical fields, one-way on the rest. Webhook on offer accepted, not just on hired.
• Comms: Slack and Google Workspace. Per-req hiring rooms, debrief threads, and an offer-accepted celebration channel for visibility across the company.
• Sourcing: LinkedIn Recruiter, Apollo, or Gem feeding talent pools in Ashby with dedupe and enrichment at the boundary, not after, so duplicate candidate records never make it past the door.
• Assessments: CodeSignal, HackerRank, or CoderPad, results posted back to the candidate scorecard so analytics on assessment-to-offer hold up under scrutiny.
• Background and references: Checkr or HireRight on the background side, a custom or Ironclad flow on references with results landing on the Ashby record before the offer is sent.
• Analytics: Ashby's native dashboards for funnel work, a downstream warehouse (BigQuery, Snowflake) for cross-system metrics like cost-per-hire and quality of hire.

The order matters. Build the HRIS sync and the comms layer first, because they pay for themselves the day after you ship them. The analytics warehouse is the last piece, because it needs the rest of the stack to be clean before the numbers mean anything.

What ROI Actually Looks Like

Numbers we see when a hire-to-onboard integration is built properly (indicative, not promised, depends on hiring volume and stack maturity):

• Talent ops admin time per hire typically drops from 3-5 hours to 30-45 minutes.
• Day-one ready rate (laptop, Slack, tools provisioned before start) lands between 95% and 100%, up from the usual 60-75%.
• Time-to-productive shortens 1-2 weeks because the new hire is not waiting on access.
• Hiring manager interruptions to talent ops drop 60-80%, because they can see status in Slack.
• Source ROI reports stop drifting, because attribution is enforced at the form level rather than reconstructed at month end.
• At 100 hires a year, the saved ops time alone usually pays for the build inside the first quarter. At 300 hires, it pays back in weeks.

Where Teams Go Wrong

Trusting the native integration to handle everything. The Rippling-Ashby connector covers basic fields. It does not handle the field mapping you actually need, the access templates, or the comms layer. Treat it as a starting point, not the finished product.

Treating Ashby as the source of truth for everything. Ashby is the system of record for the funnel. Once a hire is closed, the HRIS is the source of truth. Build the integration so the handoff is explicit, not ambiguous, and document which field lives where so the team stops debating it in standups.

Skipping the canonical org chart. If departments, levels, and titles can drift between systems, they will. Pick one place where the canonical list lives (often a small table in a warehouse or Supabase) and enforce it both ways. Anything else is a forever-cleanup project.

Provisioning on day one, not before. Day-one provisioning is too late. The right trigger is offer accepted, not hired, with a hold flag that releases on a known start date. New hires should not be the QA team for the access flow.

Ignoring rejected and withdrawn candidates. The talent pool of strong-but-not-now candidates is a high-leverage source for the next req. Wire it so rejected candidates with positive scorecards automatically land in a nurture sequence keyed to role family, not in an inbox no one reads.

Where Moonira Comes In

Ashby is one of the cleanest platforms a growing company can adopt. The leverage shows up in the seams between Ashby and the rest of the people stack, which is where we build. The product team at Ashby has done the hard work of unifying sourcing, ATS, scheduling, and analytics. The job in front of you is to wire the rest of the company to it.

We typically deliver a complete Ashby integration build (HRIS sync, Slack hiring rooms, sourcing pipeline, analytics layer) in four to six weeks for a team hiring 50 to 300 people a year. If you are running Ashby and any of the symptoms in this piece sound familiar, the gap is fixable. Talk to us when you are ready to close it.