How hiring works in Arche: posting a role, taking applications through your public careers page, moving candidates across pipeline stages, running interviews, and sending offers that turn an accepted candidate into an employee.

Overview

The recruiting module follows one flow from end to end. You create a job posting and publish it, applications come in (either from your public careers page or entered by your team), each application moves through pipeline stages, you schedule interviews and record feedback, then you create and send an offer. When the offer is accepted you hire the candidate, which creates the employee record.

Five record types do the work:

Record	What it is
Job posting	The role you are hiring for, with description, requirements, salary range, headcount, and deadline.
Candidate	A person. One candidate can apply to several postings. Candidates are unique per company by email.
Application	One candidate applied to one posting. This is what moves through the pipeline. A candidate cannot apply to the same posting twice.
Interview	A scheduled session tied to an application, with interviewers, type, and feedback.
Offer	A compensation offer tied to an application, with its own approval and acceptance flow.

Recruiting is a licensed module. If your plan does not include RECRUITING, these pages and endpoints are not available. Two permissions gate everything: view_recruiting to see the pipeline, and manage_recruiting to create, move, and act on records. Like every other module, recruiting data is isolated per company. You only ever see your own.

The screens live under Recruiting in the sidebar: Job Postings (/recruiting/jobs), Applications (/recruiting/applications), Candidates (/recruiting/candidates), Interviews (/recruiting/interviews), Offers (/recruiting/offers), and Pipeline settings (/recruiting/pipeline).

Job postings

A posting holds the title, description, requirements, responsibilities, benefits, employment type, work mode, location, salary range, headcount, and an optional application deadline.

Employment type is one of full-time, part-time, contractor, intern, or temporary. Work mode is onsite, remote, or hybrid. Salary defaults to KES, and the range is only shown publicly when you tick show salary, otherwise it stays internal.

A posting moves through these statuses:

draft → open → paused → open → closed
                 ↓
              filled

Status	Meaning
`draft`	Created but not visible publicly. Not accepting applications.
`open`	Published and accepting applications.
`paused`	Temporarily hidden. You can publish it again to reopen.
`closed`	Manually closed. Not accepting applications.
`filled`	All `headcount` positions hired. Set automatically.

Publish from a draft or paused posting. Pausing only works on an open posting. You can close any posting that is not already closed or filled. A filled posting cannot be edited. When you publish you choose channels (the default is careers-page).

Postings track an application count that increments each time an application is received, so you can see interest at a glance.

The public careers page

Each company gets a public, no-login careers page at /careers/{slug}, where {slug} is your company subdomain. Only open postings appear there. Candidates can search by title or location and filter by employment type and work mode. Clicking a role opens its own page at /careers/{slug}/jobs/{jobId}, with the full description, requirements, responsibilities, benefits, and an Apply button; that page is what gets shared or indexed for a specific opening. The page returns a sanitised view of each posting (title, description, requirements, salary if shown, deadline), never internal fields.

When someone applies through the careers page:

They fill in name, email, and optional phone, cover letter, LinkedIn and portfolio URLs, current company, and current title.
They can attach a resume. Only PDF is accepted, up to 5MB. The file is checked by its actual content (the %PDF header), not just the name or extension: the same rule applies everywhere a resume is uploaded, including when your own team attaches one to an application.
Any custom form fields you configured for that posting are shown and validated.
They must tick the consent box agreeing to data processing for recruitment. The Submit button stays disabled until name, email, and consent are provided.

On submit, Arche finds an existing candidate by email or creates a new one (source careers-page), then creates the application. If that email already applied to this posting, the duplicate is rejected with a clear message. If the deadline has passed, the application is refused. The application event triggers a confirmation-email attempt when the application_confirmation template is active. Delivery depends on the company's email configuration and provider; a saved application does not prove inbox delivery.

The public apply and resume-upload endpoints are rate limited (apply: 5 requests per minute; resume upload: 3 per minute) to deter abuse.

Custom application fields are configured per posting in the Application Form Builder. Supported field types include text, textarea, number, date, email, phone, url, select, multi-select, radio, and checkbox, each optionally marked required.

Applications and the pipeline

Every application carries a status and a current stage. These are two different things. Status is a fixed lifecycle value; the stage is your own configurable pipeline column.

Application status is one of:

applied → screening → interviewing → offered → hired
                                              → rejected
                                              → withdrawn

Pipeline stages are fully yours to configure under Recruiting → Pipeline. A new company starts with these defaults:

Stage	Notes
Applied	Default landing stage for new applications
Screening
Interview
Assessment
Offer
Hired	Terminal stage
Rejected	Terminal stage

You can add, rename, recolour, reorder, and deactivate stages. Deactivating is a soft delete, the stage is hidden but history is kept. New applications land in the stage marked as default (Applied out of the box).

Moving an application uses the stage's configured status mapping, not its name. Renaming a stage does not change its meaning. An unmapped non-terminal stage leaves status unchanged; an unmapped terminal stage is treated as rejection. You can add a note with a move. Hired, rejected, and withdrawn applications cannot be moved. Use the hire action to create an employee: moving into a stage mapped to hired is rejected.

Two views help you work the pipeline for a single posting:

Kanban: applications grouped into columns by stage, plus an unstaged group for any without a stage.
Pipeline summary: a count of applications in each stage.

To reject an application, supply a reason. Status becomes rejected, the reason and timestamp are recorded, and the application is moved to the Rejected stage if one exists. You cannot reject a candidate who is already hired. Withdraw marks an application withdrawn (use this when the candidate pulls out).

Your team can also add an application directly (status starts at applied) for candidates you sourced yourself, and upload or replace a resume on the application (PDF only, same rule as the public form). The application detail page shows the cover letter, notes, an inline resume preview, and a count of related interviews and offers. If AI features are enabled for your company, recruiters with manage_recruiting also get AI Screen Resume and AI Interview Questions helpers there.

Candidates

A candidate is the person behind one or more applications. Candidates are unique per company by email, so the same person applying to two roles is one candidate with two applications. The record holds contact details, resume, LinkedIn and portfolio URLs, current company and title, years of experience, expected salary, a rating, free-form tags, and notes.

Source captures where they came from: careers-page, linkedin, referral, agency, job-board, direct, or other. Candidate status is active, hired, rejected, withdrawn, or blacklisted. The candidate detail page links out to each of their applications and the postings they applied to.

Interviews

Schedule an interview against an application. You set the date and time, duration (defaults to 60 minutes), the interviewer(s), and the type:

Interview type
`phone`	`video` (default)
`onsite`	`panel`
`technical`	`case-study`

If you select a configured meeting provider, Arche can request a Zoom, Google Meet or Microsoft Teams meeting and attach its join link. This requires a working integration. The host-only start link is kept internal and never sent to candidates.

Interview status runs scheduled → in-progress → completed, with cancelled and no-show as off-ramps. Scheduling an interview for an application that is still applied or screening automatically bumps it to interviewing. You cannot schedule an interview for a rejected or withdrawn application.

After the interview, submit feedback: notes, an overall rating and a recommendation. The API also accepts a scorecard; the current web feedback form does not expose it. The recommendation is one of strong-hire, hire, no-decision, no-hire, or strong-no-hire. Submitting feedback marks the interview completed; feedback is rejected for cancelled interviews or an interview scheduled in the future. Cancelling requires a reason, and you cannot cancel an interview that is already completed or update one that is completed or cancelled.

Offers

An offer is tied to an application and carries the salary, currency (defaults to KES), salary period (annual, monthly default, or hourly), optional signing bonus, equity, benefits summary, start date, and an optional expiry.

Offers move through their own lifecycle:

draft → pending-approval → approved → sent → accepted
                                           → declined
                                           → expired
                                    → withdrawn

Status	What it means
`draft`	Being prepared. Only draft offers can be edited.
`pending-approval`	Waiting on an approver.
`approved`	Cleared internally, ready to send.
`sent`	Marked sent with an acceptance link; this does not establish inbox delivery.
`accepted`	Candidate accepted.
`declined`	Candidate declined (a reason is recorded).
`expired`	Passed its expiry.
`withdrawn`	Pulled before a response.

The usual path: create the offer (the application must not be rejected or withdrawn), approve it (records who approved and when), then send it. Sending generates a one-time secure acceptance link and sets the application to offered. Only an approved offer can be sent, and only a sent offer can be accepted or declined.

A candidate can accept through the link without logging in. Arche checks the offer is still sent and not expired, records the acceptance time, the candidate's IP, and user agent as an audit trail, then invalidates the link so it cannot be reused. You can also record acceptance or a decline manually from the Offers screen. You cannot withdraw an offer that is already accepted, declined, or expired.

Hiring a candidate

Hiring is the final step and it crosses into the HR module. The normal workflow is to accept an offer and then trigger a hire, supplying the new employee number, hire date, and employment type. The backend also permits hiring without a formal accepted offer for offline offers, but rejects hiring after a declined, withdrawn, or expired offer unless a new accepted offer exists. Arche:

Checks no existing employee already uses the candidate's email.
Creates the employee record (department and position fall back to the posting's).
Sets the application to hired and the candidate to hired.
Marks the posting filled once the number of hires reaches its headcount.

This emits an internal candidate hired event, so other modules can pick up from there. Onboarding listens for it: if your company has an active onboarding template marked as the default, a checklist is created for the new hire automatically, with tasks due-dated off their hire date. See Onboarding Templates & Checklists for how that template is built.

Frequently asked questions

A candidate says they cannot apply twice. Is that expected? Yes. One candidate can hold only one application per posting. The same person can still apply to other open roles.

Why do some applications have no stage? They were created before a default stage existed, or the default stage was changed. In the Kanban view they show under the unstaged group. Move them into a stage to bring them into the pipeline.

Does renaming a stage change application status? No. Status follows the configured mapping. Review that mapping when changing the purpose of a stage. The current Pipeline settings form does not expose the mapping field; changing it requires an administrative API update.

Can candidates see our salary range? Only if show salary is enabled on the posting. Otherwise the range stays internal and is not returned to the public careers page.

Is the public careers page open to anyone? Yes, it needs no login and only lists open postings for your company. Applications and resume uploads are rate limited, resumes are content-validated, and applicants must give explicit data-processing consent before submitting.

What happens to the offer link after acceptance? It is single use. Once a candidate accepts, the token is cleared so the link cannot be used again. Re-opening the cleared link no longer retrieves the offer.

Who can do what? view_recruiting lets a user see postings, applications, candidates, interviews, and offers. manage_recruiting is required to create or change anything: publishing postings, moving stages, scheduling interviews, submitting feedback, and creating, approving, sending, or actioning offers.

Applicant Tracking