Employee & trainer referrals

A referral is a first-class record, not a tip passed along in a hallway. Any signed-in employee (/me) or trainer (/trainer) can put a name forward for either hiring pathway, HR reviews it in one list, and the system automatically tracks whether the referred person went on to apply and get hired.

What it is

Jadiroon has two hiring pathways — employment (open Positions) and training (open TrainingPositions) — and, until now, the only way into either was a candidate applying on their own from the public board. Referrals add a second door: someone already inside the workspace vouching for someone outside it.

All four combinations work, from both portals:

So a trainer can refer a friend for a job, and an employee can refer someone into a training cohort — not just the pathway each portal is "about."

How to refer

Both portals mount the same Refer someone form — the employee portal at /{slug}/me/referrals, the trainer portal at /{slug}/trainer/referrals. The form walks in one page:

1. Pathway toggle. Choose Employment or Training first. Switching pathway clears the position field below it, since the two lists don't overlap.
2. Position picker. A searchable list of every position currently open for that pathway — the same visibility rule the public job board and training board use. If a position is marked Saudi nationals only, it still appears in the list, with an orange warning badge and a banner explaining that a referral into that position must be a Saudi national to be eligible for hire. It is not hidden and not blocked — see Privacy below for why nationality isn't collected here at all.
3. Candidate details — the referred person's full name and email (both required), and an optional phone number. That's it. No CV, no ID, no other identifying data.
4. Relationship. A required dropdown: former colleague, current colleague (different team), direct report or manager of mine, family member or relative, friend, professional acquaintance, or other. This isn't small talk — it drives the conflict-of-interest flag (see What HR sees).
5. Note (optional) — any context that helps the hiring team, e.g. why this person is a good fit.
6. Attestation. A checkbox the referrer must tick before the form will submit. It reads (paraphrased): "I personally know this person and have their permission to share this information for this specific opportunity — I understand the workspace will contact them directly, and this is not a bulk or unsolicited referral." This checkbox is load-bearing — see Privacy for exactly what it does and doesn't mean legally.

The submit button stays disabled until a position, name, valid email, relationship, and the attestation are all in place. On success the form clears and the new referral appears immediately in My referrals below it, with a status chip.

What happens next

A referral moves through a small, mostly-automatic lifecycle:

SUBMITTED ──(HR marks Invited)──> INVITED ──(referred person applies)──> APPLIED ──(hire confirmed)──> HIRED
     └──────────────────────────────────────(HR declines)───────────────────────────────────────────> DECLINED

• SUBMITTED — the moment the referrer hits submit. HR administrators get a notification immediately.
• INVITED — an HR action, marking that the workspace has reached out.
• APPLIED — set automatically, with no HR click required. If the referred person later applies to that exact position using the same email address the referrer entered, the system recognizes the match, links the application to the referral, and advances it. This works from either apply flow — the public job board or the trainer application form.
• HIRED — also set automatically, the moment that linked application reaches the HIRED stage in the hiring or trainer pipeline.
• DECLINED — an HR action, at any point before HIRED.

The referrer gets a notification at every change — when HR invites, when the person they referred actually applies ("thanks to your referral"), and when that person is hired. They track all of this themselves in My referrals, with no need to ask HR for an update.

What HR sees

The review list lives at /{slug}/app/hire/referrals (hire.referrals.view to see it, hire.referrals.edit to act on it — both are covered automatically by the existing hire.* wildcard grants for Talent Acquisition and HR Admin roles).

The table shows, per referral: candidate name/email/phone, position and pathway, referrer name and email, relationship, current status, submission date, and the Art. 14 notice status (see Privacy). Filters at the top narrow by pathway, by status, and two toggles:

• Conflict of interest only — referrals where the relationship is direct report or manager of mine or family member/relative.
• Overdue Art. 14 notices — referred people who haven't been told we hold their data, past the legal deadline. This is the loudest control on the page for a reason.

Status actions appear as buttons on each row, restricted to whatever transition is actually valid from that row's current status (e.g. a SUBMITTED row offers Invite and Decline; an APPLIED row offers Mark hired and Decline). You can't invite a referral that's already been marked hired, because the button simply isn't there.

Conflict of interest. Referring a relative, or your own manager, or someone who reports to you, is allowed — it isn't blocked. But the relationship the referrer disclosed determines whether the row is flagged: Direct report or manager of mine and Family member or relative both set a visible Conflict badge next to the candidate's name, so HR knows to route that referral through a skip-level reviewer rather than the referrer's own chain before proceeding.

Privacy

This section matters more than the rest of the page, so read it even if you skim everything else. It's written for the employee who's about to type in a friend's phone number, not for a lawyer.

We ask for the minimum. At the point of referral, we only collect: the referred person's name, email, an optional phone number, the referrer's stated relationship to them, and an optional short note. We deliberately do not collect a CV, national ID/Iqama, nationality, or any salary expectation at this stage — those only get collected from the referred person directly, if and when they apply themselves.

The checkbox is not their consent — and it can't be. Under Saudi PDPL (Art. 5), consent has to come from the person themselves; a referrer legally cannot consent on someone else's behalf, no matter how well they know them. So the tickbox you check isn't a consent record — it's an attestation: you vouching that you genuinely know this person and that they're fine with you passing their name along for this specific opportunity. The actual legal basis the workspace relies on to hold this data briefly is a narrower exception (the "legitimate interest" basis, Art. 6(4)) — which is only available because nothing sensitive is being collected and the purpose is this one specific opportunity, not a mailing list.

The referred person is told automatically, and told who referred them. Saudi PDPL (Art. 14) requires that when we collect someone's personal data from a third party rather than from them directly, we notify them — naming the source — without undue delay, and within 30 days at the latest. Jadiroon does this itself: the moment a referral is submitted, an email goes out to the referred person explaining exactly what information we hold about them, that it came from a named referrer (their name is disclosed, as the law requires), the legal basis for holding it, and how to have it deleted immediately just by replying. This isn't optional or something HR has to remember to trigger — it fires on creation.

Nothing gets silently missed. If that notice email fails to send, or the 30-day window passes without it going out, that referral shows up as overdue in the HR list (see What HR sees) — it's never just quietly lost.

Limits

• One open referral per person, per position. You can't submit a second referral for the same email address against a position that already has an open one (Submitted, Invited, or Applied).
• You can't refer yourself. If the candidate email matches your own account's email, the referral is rejected.
• Up to 10 referrals per rolling 30 days, per referrer. This exists to keep referrals meaningful rather than a bulk-submission channel — an unlimited box (especially with any future referral bonus) predictably produces speculative, low-quality submissions.
• Saudi-nationals-only positions are flagged, not blocked, at referral time. Nationality genuinely isn't collected when you refer someone, so the platform can't verify eligibility at this stage even if it wanted to — the real check happens later, when the referred person applies and their nationality is captured directly from them. The warning is there so you don't waste a referral on someone who won't ultimately be eligible for that specific role.
• If the person is already in the pipeline, the referral is rejected rather than silently duplicated — this keeps the automatic APPLIED/HIRED linking accurate.

Next

The next page covers CV screening — including how a referred candidate's application is screened exactly like any other, once it lands in the pipeline.