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 hire the candidate, which creates the employee record. Your company decides whether a hire must come from an accepted offer (see Hiring a candidate).

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 most of it: view_recruiting to see the pipeline, and manage_recruiting to create new records and act on every posting. With view_all_recruiting you see everything in the module. Without it you see the postings whose hiring team you are on, until your end date, and the applications you interview on. Only a posting's hiring manager sees its offers, moves and rejects its candidates, and schedules its interviews; reviewers and interviewers also rate candidates, which needs only view_recruiting, and give interview feedback. A person whose name is on an interview gives feedback on it with no recruiting permission at all (see Interviews). Rating and feedback on every posting need manage_recruiting as well as view_all_recruiting: with view_all_recruiting alone you see everything, and rate or give feedback only where your hiring team role or an interview allows. Like every other module, recruiting data is isolated per company. You only ever see your own.

The screens live under Talent in the sidebar: Job Postings (/recruiting/jobs), Applications (/recruiting/applications), Candidates (/recruiting/candidates) with view_recruiting, each showing only the records in your reach, Interviews (/recruiting/interviews) for hiring team members and anyone named on an interview, whose All interviews tab needs view_recruiting, Offers (/recruiting/offers) with view_recruiting, view_offers or approve_offers, showing only the offers you may read, and Pipeline Settings (/recruiting/pipeline) with manage_recruiting. The menu shows only what concerns you: Job Postings, Applications and Candidates appear when you are on a hiring team today (or reach every posting, or hold manage_recruiting), Interviews also appears when your name is on an interview panel, and Offers appears on a hiring team or with view_offers or approve_offers. Someone on no hiring team and no panel sees none of them. The mobile app shows My Interviews the same way.

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. Publishing puts the role on your careers page; the web has no channel picker. If the application deadline has passed, move it to a later date before you publish or reopen the posting.

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

A posting can also carry a target fill date, the day your team aims to fill it by. The Job Postings list shows how far away it is ("12 days to target", "Target is today", "3 days past target"), and the posting page shows the date. See Stage targets and overdue candidates.

Hiring team

Each posting has a hiring team: the people who work on that job, what each may do, and until when. The team is the Hiring team card on the job posting page. Someone on a posting's team sees that posting and its candidates and nothing else in recruiting, unless their role holds view_all_recruiting.

Team role	What they can do on this posting
Viewer	See the posting, its candidates and their interviews.
Reviewer	Also rate candidates and give interview feedback.
Hiring manager	Also move and reject candidates, schedule and change interviews, draft and send offers, change the posting, and change its hiring team.

The team role decides which posting and what may be done on it, with view_recruiting. A Department Manager who is a job's hiring manager therefore runs that job's hiring without HR rights. The Hire step stays with HR and recruiters (manage_recruiting): it creates the employee record. Offers hold pay, so on a team only the hiring manager sees them; people with view_offers see every offer, and people with approve_offers (the Finance Manager role, for one) approve any drafted offer.

End dates. Each member can have an access until date: the last day, on your company's calendar, that they can see the posting. From the next day they see nothing of it, without anyone having to remove them. Three days before the last day, Arche sends an in-app message to the member and to the posting's hiring manager. To extend access, change the date; to end it early, remove the person.

Adding someone. Open the posting and choose Add person on the Hiring team card. If the posting has a department with a head, Arche suggests that person first. Pick the person, a role and an optional end date. Only current employees of your company can join a team. The hiring manager you choose on the posting form is the posting's hiring manager on the team too: choosing someone else there takes the previous hiring manager off the team.

Who can change the team. The posting's hiring manager and recruiting staff (manage_recruiting with view_all_recruiting). A hiring manager without view_all_recruiting can add, change and remove reviewers and viewers, but not hiring managers, and cannot change their own place on the team or their own end date: ask recruiting staff.

Interviewers are not team members. Being listed on an interview lets someone see and review the application they interview, nothing more.

Outside consultants

There are no guest accounts. To bring in an outside consultant or an agency recruiter for one hire:

Add them as an employee with the employment type Contractor. Do not set a future termination date when you add them: termination takes effect at once.
Give them a sign-in with the Hiring Panel role. It holds view_recruiting and their own notifications, nothing else: no leave, payroll, employee records or reports.
Add them to the posting's hiring team as a Reviewer with an access until date.

Until that date they can see that job and its candidates, rate the candidates and give feedback on its interviews. They cannot move, reject or hire candidates, see offers or schedule interviews. They find the job, its applications, its candidates and its interviews in the Talent menu: they rate a candidate on the candidate's page and give feedback on the Interviews page. The same role suits a member of your own staff who only sits on hiring panels.

After the end date they can still sign in but see nothing in recruiting. When the engagement ends, terminate their employee record. A consultant's employee record uses one seat of your plan's employee limit, like any other employee who is not terminated; it costs nothing extra unless you reach that limit.

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 that are open to the public appear there (see Internal vacancies). 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, nothing new is saved, but the applicant still sees the normal thank-you receipt, so the form never confirms who has applied. 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.

Internal vacancies

Each posting has a Who can apply setting:

Setting	Who sees it
Everyone (public careers page)	Anyone, on the careers page and through its link. The default.
Employees only (internal)	Signed-in employees only. The careers page, its links and the public apply form treat it as not found.
Employees first, then public	Employees only until the date you choose, then the public too. The date follows your company's calendar.

Employees find vacancies under Open positions in the sidebar (/open-positions). Every current employee sees every open vacancy there, internal and public, without a recruiting permission. People without an employee record in the company (partner staff, for example) do not. They apply as themselves: their name and email come from their employee record, and they can add a cover letter and a PDF CV. They answer the posting's own application questions, as an outside applicant does on the careers page, and the same required answers apply. Applications close at the end of the deadline day in your company's time zone. The page shows which roles they already applied to and where each application stands. Arche does not tell their line manager, unless that manager is the hiring manager for the posting; the application is visible to the people who see that posting's applications. Their candidate record is marked internal and tied to their employee record.

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 Talent → Pipeline Settings. A new company gets these defaults the first time it uses recruiting:

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, and set What this stage means (the status a move into it sets). Deactivating is a soft delete, the stage is hidden but history is kept, and a deactivated stage can be restored. A stage that still holds applications in progress cannot be deactivated: move them first. Stage names are unique, including deactivated ones. 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. When an action changes an application's status (scheduling its first interview, making, sending or recording an offer, hiring), its card moves forward to the stage that carries that meaning. A card never moves backwards past a stage of your own.

Moving a card to the offer stage

What happens when you drag a card to a stage that means offered depends on Require an accepted offer before hiring (see Hiring a candidate):

On: a candidate reaches the offer stage by getting an offer. Dropping the card opens Make an offer for that candidate. Save the draft and the card moves. Cancel and the card stays where it was. A candidate who already has an offer in progress moves straight away.
Off: the card moves, and Arche asks whether you want to draft a formal offer now.

The same rule applies when the assistant moves a candidate. A card in the offer stage shows its offer's state. If the offer was declined, withdrawn or expired, make a new offer or move the candidate back to an earlier stage.

Stage targets and overdue candidates

Each stage can have target days: how many days a candidate should spend in it. Set it under Talent → Pipeline Settings when you add or edit a stage; leave it empty for no target. Arche records the moment an application enters a stage, by any route (a move, a rejection, a status change that moves the card, or a new application landing in the default stage).

A candidate is overdue when the days they have spent in their current stage, counted on your company's calendar, are more than the stage's target. Hired, rejected and withdrawn applications are never overdue. Overdue candidates show a red Overdue (N days) badge on the pipeline boards, and each posting shows how many of its candidates are overdue.

Once a day, each hiring manager whose postings have overdue candidates gets one in-app message listing the postings and how many candidates are waiting too long in each. Nobody gets a message when nothing is overdue.

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

Kanban: applications grouped into columns by stage, plus a New / Unassigned column for any without a stage or in a deactivated one.
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). Rejecting or withdrawing an application, or moving it into a rejection stage, also withdraws any offer on it that is not yet accepted, and its acceptance link stops working.

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, other, or internal (an employee who applied from Open positions). 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.

Deleting a candidate removes the candidate, their applications, interviews and offers, deletes their stored resumes and offer letters, clears the results of AI resume screenings linked to them and replaces their name with "An applicant" in notifications about their applications. A file that another candidate's record also links to is kept for that record. If storage refuses to delete a file, nothing is deleted and you can try again. A hired candidate, or one who accepted an offer, cannot be deleted.

Keeping and removing applicant data

Your company decides how long Arche keeps the personal details of people who applied and were not hired. Under Talent → Pipeline Settings, set Remove applicant data after to a number of months from 1 to 120. Leave it empty to keep applicant data, which is how every company starts. Changing it needs manage_recruiting_config. As you type a period, the page shows how many applicants the next run would anonymise.

Once a day, Arche removes the personal details of every applicant who meets all of these:

every one of their applications was rejected or withdrawn, so none is still open;
they were not hired and hold no accepted offer;
they are not an internal applicant (an employee who applied from Open positions) and are not blacklisted;
their last activity is older than the period. Activity is the latest of a rejection, a change to one of their applications, and the closing of a posting they applied to. For a candidate with no application, it is the last change to their record. Months are counted on your company's calendar.

This also covers people in your talent pool who never applied, counted from their last update.

What is removed:

Where	Removed
Candidate	The name becomes "Removed applicant". Email, phone, resume, LinkedIn and portfolio links, current company and title, expected salary, tags, notes and custom answers are cleared.
Applications	Cover letter, form answers, rejection reason, notes and resume.
Interviews	Notes, meeting link and cancellation reason, and each person's written feedback and scorecard.
Offers	The salary is set to 0, and the signing bonus, equity, benefits, notes, decline reason, offer letter and the address and browser recorded with a response are cleared. An accepted offer never qualifies.
Files	Stored resumes and offer letters are deleted from storage.
AI audit log	The result of a resume screening the assistant ran on the applicant's stored resume.
Notifications	In-app notifications that named the applicant say "An applicant" instead.

What is kept, so your hiring figures still count the applicant: the candidate record with its status, source, rating and years of experience; each application's status, stage and dates, including when the applicant gave consent; interview ratings and recommendations; and each offer's status and dates. The candidate list shows the record as "Removed applicant" with the day the data was removed.

If a stored file cannot be deleted, nothing about that applicant changes and the next run tries again. Each run that removes anyone writes one entry to your audit log with the number of applicants.

Some things are not removed. The audit trail keeps its record of what was done to the applicant's records; it stores record ids and the address of each request (including any search terms in it), not the details on the applicant's record. Emails already sent stay in inboxes. AI chat history keeps whatever the assistant showed or was told about the applicant, including resume text pasted into the AI Screen Resume helper and its result, and files attached to a chat follow the chat's own clean-up.

When a period is set, the careers application form tells applicants: "We keep your application for 6 months after the job closes, then remove your personal details", with your own number of months. A removed applicant has no email address on file, so if the same person applies again they start as a new candidate. A removed applicant's record cannot be edited or given a resume, a new application, an interview or an offer, and cannot be hired: add the person again as a new candidate. A resume another candidate's record also links to is not deleted.

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, give your feedback: an overall rating from 1 to 5, a recommendation and notes. Each person on the panel gives their own feedback, and nobody else can change it. You can edit yours until the application is hired, rejected or withdrawn. The recommendation is one of strong-hire, hire, no-decision, no-hire, or strong-no-hire. The API also accepts a scorecard; the web form does not show it.

Who can give feedback on an interview:

Anyone whose name is on that interview. They need no recruiting permission, so a member of staff with the Employee role can sit on a panel. On the web they open Talent > Interviews, My interviews tab. In the mobile app they open Services > My Interviews.
The posting's reviewers and hiring manager, and recruiting staff, with view_recruiting.

An interviewer of one round cannot give feedback on another round they are not on. Feedback is refused on a cancelled interview, on one the candidate did not attend (no-show), and on one that has not taken place yet.

Until you give your own feedback on an interview you are on, you see how many others gave theirs, but not what they wrote. This keeps each opinion your own. The posting's hiring manager and recruiting staff always see all of it. The hiring manager gets a notice when someone gives feedback. The notice opens that interview's feedback; a hiring manager without recruiting access is told to ask HR for it. Each interviewer gets a notice and an email with a calendar invitation when they are put on an interview, and an updated invitation when its time, length, place or link changes. When the interview is cancelled, or they are taken off it, they get a notice and a calendar cancellation. The interviewer's invitation never carries the scheduling notes or the host link. You can change both emails under the company's email templates (Interview Panel Invitation and Interview Panel Cancellation).

The first feedback marks the interview completed. 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`	Reserved. Nothing moves an offer into this status: you approve a draft directly.
`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, withdrawn or hired), approve it (records who approved and when), then send it. Making the offer sets the application to offered and moves its card to the offer stage. You can make it from the board, from the application page (Make an offer) or from the Offers page. Arche records who drafted each offer and who last changed it. Turn on Someone else must approve an offer under Talent → Pipeline Settings to stop either of them from approving it; leave it off if one person handles hiring. With it on, the posting's hiring managers get a notice when someone drafts an offer (or, when the drafter is the only hiring manager, the recruiting staff who can manage every posting). If accepted offers are not required, a hire can skip the offer, so this setting only governs offers that are made. Sending generates a one-time secure acceptance link and sets the application to offered. An offer sent without an expiry gets one 30 days out. Hiring withdraws any other offer still in play on the application. A rejection email to the candidate never includes your reason. Only an approved offer can be sent. A sent offer can be accepted or declined. For an offer made by letter, phone or in person, use Record acceptance on the approved offer: it is marked accepted and nothing is emailed to the candidate.

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. If the application was rejected or withdrawn in the meantime, the link is refused. You can also record acceptance or a decline manually from the Offers screen; after you record an acceptance, Arche offers to hire the candidate straight away. When an offer is accepted, the posting's hiring managers and the person who drafted the offer get a notice. It opens the application with the hire form ready. 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. Under Talent → Pipeline Settings, Require an accepted offer before hiring decides how it starts:

On (the default): hire from the candidate's accepted offer.
Off: HR can also hire straight from the application, and offers stay available when you want them.

Only people with manage_recruiting_config can change the setting. Either way, a hire is refused after a declined, withdrawn or expired offer unless a new accepted offer exists. For an outside candidate you confirm the employee number, hire date and employment type. The form starts with the accepted offer's start date and, when your company has set up employee numbers (see Employee profiles), the next number in your sequence. Keep it or type your own. Arche gives out the next number when you press Hire, so two people hiring at once never get the same one; if the number shown was taken a moment before, the message after the hire says which number was given. A number you type must not belong to anyone else in your company; if it does, the form tells you the next free number. Arche:

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

Internal applicants already have an employee record, so hiring one creates no new employee and needs no employee number. You enter the date they take up the role, and by default they move into the posting's department and position (untick Move them into this job posting's department and position to keep their current ones). Their record changes as soon as you hire them, and the change is filed in their employment history as of the date they take up the role. Moving someone changes their employee record, so it needs the Manage employees permission (and, for the department, the right to change org structure). Without it the option is greyed out: you can still hire them, and HR updates their record afterwards. Nobody can record their own hire. Their manager and pay stay as they are: change those on their profile. The application and candidate are marked hired and the posting fills as above. No onboarding checklist is started for them.

For an outside hire, 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. When your team adds an application, or an employee applies from Open positions, a duplicate is refused with a message. From the careers page the applicant is not told.

Why do some applications have no stage? They were created before a default stage existed, the default stage was changed, or their stage was deactivated. 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 What this stage means, which you set on the stage in Pipeline settings. Review it when you change the purpose of a stage.

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 that are open to the public. Internal vacancies never appear there. 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, within the reach described under Overview. On a posting you host (its hiring manager, or manage_recruiting with view_all_recruiting), view_recruiting is enough to change it: publish and close it, move and reject its candidates, schedule its interviews, and draft, send and action its offers. manage_recruiting is required to create postings, candidates and applications, and to hire. view_offers reads every offer; approve_offers approves any drafted offer, never your own. Rating a candidate and submitting interview feedback need only view_recruiting, where your hiring team role or an interview allows it (feedback on an interview you are on needs no permission); on every posting they need manage_recruiting with view_all_recruiting. Without view_all_recruiting, the hiring team role on each posting narrows the rest further.

Someone's access to a posting ended. Do they still see it? No. Access lasts to the end of the access until day on your company's calendar. From the next day the posting and its candidates are gone from their lists and links, even before anyone removes them from the team.

Applicant Tracking