How we wired hiring into the rest of the platform (so a new hire's first day already works)

A Monday morning that didn't work

Picture a small business hiring their fourth dispatcher. The candidate did three rounds, signed an offer letter, and is supposed to start Monday at 8 AM.

Monday at 7:45 the new hire shows up. They have no email account. No chat access. No CRM login. No access to the dispatch board. The HR person and the IT person spend most of the day reconciling lists, copying permissions from a similar role, and chasing whoever provisioned the last new hire.

The new dispatcher technically started Monday. They effectively started Wednesday afternoon.

This was every new-hire week at one of the businesses we ran. The applicant tracker followed the candidate beautifully through interviews and offer letters, then dropped them off at "hired" and left the operations stack to pick up the pieces. We thought the hire button should finish the hire.

The pieces of the hiring pipeline

A short tour of what ships when you sign up:

• Job postings — title, description, criteria (must-have and nice-to-have), employment type, work mode (onsite, remote, hybrid), and how many openings the role carries. Posted at yourcompany.com/careers through the SDK, so the listing lives on your domain.
• Application forms — custom forms attached to a job. Drag in the fields your hiring process actually needs. Submissions land as both a form submission and a candidate profile.
• Candidate pipeline — every candidate moves through new → reviewing → shortlisted → interview → offer → hired, with rejected and withdrawn as exits. Board view, list view, filters.
• Interview scheduling — built on the same meetings system as your other appointments. Candidates pick a slot from your hiring team's real availability, the calendar invite goes out on its own, and notes land on the candidate record afterward.
• Tiered notes — internal notes are visible to everyone on the hiring team; manager-only notes stay restricted. The tiers mirror how hiring teams already talk about candidates.
• File attachments — resumes, cover letters, portfolios. Each candidate's files live on their record, searchable from the candidate list.
• Job offers — a formal offer record tied to the candidate, generated from a contract template so the offer letter inherits your standard language without a rewrite.
• Contract linking — when an offer is signed, the employment contract attaches to the candidate's record and lives in the same contracts view as every other agreement your org holds.

The piece that changes the Monday morning

Each job posting carries a set of default permissions and a default role. When the hiring team flips a candidate to hired, those defaults provision the new hire's access automatically.

The flow looks like this:

1. A candidate's stage advances to hired — one click in the pipeline view.
2. Business Dash creates the user account from the candidate's profile email.
3. The permissions defined on the job posting attach to the new user.
4. The default team membership defined on the job posting attaches.
5. The reporting line — who they report to, who reports to them — wires up.
6. The signed employment contract attaches to their user record.
7. The new hire gets a welcome email with their login link.

By Monday at 7:45, the new dispatcher logs in and sees the dispatch board they are supposed to use. Permissions match the role. The training assigned to dispatchers is in their queue. The onboarding meetings are already on their calendar. The hire button finished the hire.

Why an applicant tracker inside the platform compounds

Most companies run a separate tracker. Those tools are excellent at the hiring side. The handoff to "now they actually work here" is what breaks.

When the tracker lives inside your operations platform, three things start to compound.

One source of truth. The candidate's email, phone, resume, interview notes, signed offer, employment contract, and current employee record all sit on the same row. When someone asks whether you had an ops applicant named Sarah back in March, that is one query instead of a search across four tools.

Defaults that travel. The permissions, team membership, and reporting line you defined on the job posting transfer to the hire. Six months later, when you post a similar role, those defaults are still right.

Closed-loop reporting. Time-to-hire, candidate-source quality, and offer-acceptance rates, plus the things that come after: 90-day retention, first-quarter productivity, manager satisfaction. Measuring your hiring takes the same data the platform already holds from the rest of operations.

How it ties into the rest of the platform

• CRM — hired candidates become real users; the candidate record stays for history while the workspace surfaces them as employees.
• Workflows — a job posting can attach to an onboarding workflow, so the hire button starts assigned training, equipment ordering, and intro meetings on its own. More on how workflow handoffs work →
• Procurement — that onboarding workflow can raise a purchase order for a laptop, phone, or uniform through the vendor portal.
• Scheduling — interview meetings use the same calendar surface as customer meetings, and hiring-team availability lives in the same staff-availability system.
• Your own site — the careers page at yourcompany.com/careers renders through the SDK. Applications land in your CRM, not on a third-party subdomain.

What changes

A hired candidate's first-day access now matches their first-day expectations. The contract they signed lives on the same record as their resume. The permissions you defined once on the job posting travel to every hire for that role, this year and next.

That is the loop we wanted, and it is why hiring was built into the platform instead of integrated alongside it.

See the hiring pipeline in action — try Business Dash →