Hiring configuration covers two settings that shape every hiring pipeline in your workspace: the auto-advance threshold (how aggressive the platform is about moving candidates forward without your intervention) and the stage email templates (what candidates hear at each step).
Where to find it
/{slug}/app/settings/hire. HR Administrator only. Three tabs: Automation, Emails, and Offer templates.
This page covers Automation and Emails. The third tab — authoring the offer document you can issue when a candidate reaches OFFERED — has its own page: Offer templates.
Internal-mobility-first toggle
At /settings/hire/automation, a toggle labelled Internal mobility first (default ON) sets the workspace-wide policy for new role postings:
- ON — when you open a new role, it stays visible to existing workspace employees only for 14 days. After 14 days, the platform flips the role to public automatically via a daily scheduled job. You can also flip it early at any time using the Open externally now button on the role's page.
- OFF — all new roles go public immediately on opening.
Per-role override: when creating or editing a role, an Audience field lets you override the workspace default for that specific role: Internal first (14-day window), Internal only (never goes public automatically), or Public immediately.
This is how Jadiroon supports the recommended Saudi hiring practice of offering internal candidates first refusal before recruiting externally.
Automatic CV screening
At the top of /settings/hire/automation, two switches control whether the platform auto-screens an applicant's CV the moment they apply — one per hiring pipeline:
- Auto-screen CVs — candidate hiring for positions (default ON)
- Auto-screen CVs — trainer hiring for trainings (default ON)
When a switch is ON, the applicant's CV is screened against the job/training description on apply, a match score is produced, and your auto-advance / auto-reject / auto-assign thresholds fire from that score. When OFF, the applicant is still recorded but receives no automatic score — they stay in APPLIED, no stage moves automatically, and the thresholds below stay dormant for that pipeline. You can always run a manual re-screen from the person's page; the toggle only governs the automatic on-apply pass.
Turn a pipeline's switch off when you want to review every applicant by hand, or to pause AI usage on that pipeline.
Per-job / per-trainer screening cap
Under each switch is an optional Max CVs auto-screened number, one per pipeline:
- Max CVs auto-screened per job — applies to each candidate hiring pipeline.
- Max CVs auto-screened per training — applies to each trainer hiring pipeline.
The counter is per single job / per single training position — not workspace-wide. A cap of, say, 50 means each individual role auto-screens its first 50 applicants; the 51st role you post starts its own count from zero.
What counts: every screening attempt on the on-apply path — a successful score, a parse failure, or a quota block. Applicants with no CV (nothing to screen) do not count.
What happens past the cap: the new applicant is still recorded, but with no automatic score — they stay in APPLIED and no auto-advance / reject / assign fires for them, exactly as if auto-screening were off. You can always run a manual re-screen from the person's page; manual re-screens are never capped.
Leave the field blank for unlimited (the default — every applicant is auto-screened). The cap is only consulted when that pipeline's auto-screen switch is on. Use it to bound AI spend on high-volume roles while keeping screening fully automatic for the first cohort.
Auto-advance threshold
A single setting at /settings/hire/automation: the score (0–100) at or above which a candidate's CV screening advances them automatically from APPLIED to SCREENED.
- Default: 70.
- Range: 0 (every applicant auto-advances) to 100 (no applicant auto-advances; you screen them all manually).
- Effect: the threshold is checked once, when the screening completes after application. It is not re-evaluated later; if you change the threshold, only future applications are affected.
Most workspaces leave the threshold at 70 and only adjust if they find themselves overwhelmed by the auto-advanced cohort (raise it) or under-screening because too many applicants are sitting in APPLIED (lower it).
Stage email templates
/settings/hire/emails lists every stage email — twelve in total, six stages × two locales (Arabic and English).
For each:
- Subject — the email subject line.
- Body — the email body, with
{variables}for substitution. Available variables:{candidateFirstName}and{candidateFullName}— the candidate's name.{roleTitle}— the role title in the workspace's locale.{orgName}— the workspace / organisation name.{interviewSlot}— slot-pick link (INTERVIEW_OFFER template only).{applicationDate}— application date (YYYY-MM-DD).{responseDays}— number of business days hiring will take to review (filled in by HR in the template or before send).{startDate}— proposed start date (offer + welcome).{salaryBand}— compensation and allowances summary (offer).{responseDeadline}— deadline by which the candidate must confirm the offer.
The last four (responseDays, startDate, salaryBand, responseDeadline) are not auto-populated by the system — HR sets them either in the template directly or by editing the email per offer before sending. The other variables are substituted automatically from candidate and workspace data.
In the seeded OFFERED template, these slots are rendered as bracketed visual placeholders ([provided in the formal offer letter]) — a deliberate visual cue to HR that the formal offer letter holds the financial detail. When you issue the offer by picking an offer template, that formal letter is now attached to this OFFERED email as a PDF (and also shown in the candidate portal), so "the attached formal offer letter" is literally this email's attachment. If you want the figures rendered inline in the email body instead, substitute {startDate}, {salaryBand}, {responseDeadline} and supply the values via a downstream integration (these variables are not passed automatically in the current release).
The seeded templates are written in formal Saudi-business voice — Arabic templates open with «السلام عليكم ورحمة الله وبركاته», close with «مع وافر التقدير، فريق التوظيف — », address the candidate as «الكريم/ة», and avoid colloquialisms ("مبروك") and calque English. English templates use parallel formal-warm register. Editing is straightforward — modify the subject or body, save, and the next time a candidate enters that stage the new copy is used. Already-sent emails are not retroactively rewritten.
1.0 template refresh
In 1.0 we rewrote all six stage templates in formal Saudi-business voice. Workspaces seeded before this release still carry the prior copy. When you open a template you have not yet edited, a small amber banner appears: "An updated default template is available — apply it?" with an "Apply update" button. Pressing it replaces the body with the 1.0 copy without touching any workspace customisations. The sidebar list shows an "update" pill on every row with a 1.0 default ready to apply.
Each template's purpose
- APPLIED (auto-fired on application) — Your application has been received.
- SCREENED — We're moving you forward to interview.
- INTERVIEWING — We're confirming your interview details.
- OFFERED — We'd like to extend an offer.
- HIRED — Welcome to the team. This is the welcome email after the hire handoff; it includes the new account setup link.
- REJECTED — We've decided not to move forward. Sent when a candidate is rejected; can be sent silently (no email) by the Reject silently action.
Multilingual matching
The candidate's preferred locale (set on the application form) determines which language's template is used. If they applied in Arabic, they receive the Arabic version of every stage email.
If a candidate did not specify a locale, the workspace's default locale is used.
Why per-role overrides are not in v0.5
Some workspaces want different email templates per role family — engineering candidates receive a slightly different message than finance candidates. This is on the v0.6 watch list. In v0.5, the templates are workspace-wide.
A workaround: write the templates to be role-agnostic and cover any role-specific content with a personal note from you, sent outside the templated flow.
What is not configurable
- The six pipeline stages themselves. Custom stages are on the v0.6 list.
- The set of variables available for template substitution.
- The sender address. Emails come from a no-reply Jadiroon-domain address in v0.5; per-workspace sender domains (using SPF/DKIM) are on the v0.6 list.
- Email scheduling. Templates fire immediately on stage change. Delayed or batched sending is not supported.
Next
Notifications you receive as HR — what arrives in your bell — is covered next.