##A Monday morning that didn't work Picture a small business hiring their fourth dispatcher.
The candidate did three rounds, signed an offer letter sent via DocuSign, and is supposed to start Monday at 8 AM. Monday at 7:45 the new hire shows up. They have no email account. No Slack. 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 ATS tracked the candidate beautifully through interviews and offer letters. Then it dropped them off at "hired" and the operations stack had to pick up the pieces. We thought the hire button should actually finish the hire. ## The pieces of the BIAB hiring pipeline A short tour of what ships when you sign up: - **Job postings** — title, description, criteria (must-have / nice-to-have), employment type, work mode (onsite, remote, hybrid), capacity (`numberOfOpenings` / `openingsFilled`). Posted at `yourcompany.com/careers` via the SDK so the listing lives on your domain. - **Application forms** — custom forms attached to a job. Drag-and-drop 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` (or `rejected` / `withdrawn`). Kanban 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 availability; the calendar invite goes out automatically; notes land on the candidate record after. - **Tiered notes** — `internal` notes are visible to everyone on the hiring team; `manager_only` notes are restricted. The note tier system mirrors how real hiring teams already discuss candidates. - **File attachments** — resumes, cover letters, portfolios. Each candidate's files live on their record, searchable from the candidate list. - **Job offers** — formal offer record tied to the candidate. Generated from a contract template (so the offer letter inherits your standard language without rewriting it). - **Contract linking** — when an offer gets signed, the resulting employment contract attaches to the candidate's record. The contract lives in the same `/dashboard/contracts` view as every other org contract. ## The piece that changes the Monday morning Each job posting has a `defaultPermissionSlugs` field and a `defaultRoleKey`. When the hiring team flips a candidate to `hired`, those defaults provision the new hire's BIAB access automatically.
The flow looks like this:
1. A candidate's stage advances to `hired` (one click in the pipeline view).
2. BIAB 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 via `staffReporting`.
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're supposed to use. Permissions match the role. The training materials assigned to dispatchers are in their queue. The calendar invites for their onboarding meetings are already there. The hire button finished the hire. ## Why an ATS-inside-the-platform compounds Most companies use a separate ATS (Greenhouse, Lever, Workable). Those tools are excellent at the hiring side. The handoff to "now they actually work here" is what breaks. When the ATS 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 are all on the same database row. When someone asks "do we have a Sarah who applied for ops in March?" the answer is one query, not 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, offer-acceptance rates — and the things that come after, like 90-day retention, first-quarter productivity, manager satisfaction. The data needed to measure your hiring is the same data BIAB already has from the rest of operations. ## How it ties into the rest of BIAB - **CRM** — candidates with employment-stage `hired` become real users; their candidate record stays for historical reference but the workspace surfaces them as employees. - **Workflows** — job postings can attach to an onboarding workflow. When the hire button fires, the onboarding stages start auto-running (assigned training, equipment ordering, intro meetings). - **Procurement** — onboarding workflow can trigger a PO for laptop / phone / uniform via the vendor portal. - **Scheduling** — interview meetings use the same calendar surface as customer meetings. Hiring team availability lives in the same staff-availability system. - **Customer portal (SDK)** — the careers page at `yourcompany.com/careers` is rendered by your site via the SDK. Applications land in your CRM, not in a third-party ATS subdomain. ## What changes If a hired candidate's first-day access matched their first-day expectations, you'd want that, right? If the contract they signed lived on the same record as their resume? If the permissions you defined on the job posting traveled to every hire for that role? That's the loop we wanted, and it's why we built hiring into BIAB instead of integrating with a separate ATS. [See the hiring pipeline in action — Try BIAB →](/signup)