Org admin manual

Welcome. As your organization's admin you sit above the day-to-day hiring: you set up the people who use HeadHunter, keep the subscription that unlocks the shared talent pool current, decide whether AI is switched on, and hold the privacy controls a donor will ask about. You can also do everything an HR manager does — this manual covers the account-level work that is yours alone, and points you at the HR manager manual for the hiring flows you share.

It's worth stating the shape of your role up front: HeadHunter only shows each person the actions their role allows, and the handful of controls in this manual are the ones only an org admin can reach. Everything here is scoped to your own organization — you can never see or touch another tenant's data, and no query in the product carries an org selector.

A few rules that hold everywhere

The same ground rules from the HR manager manual apply to you too, and two matter especially in the admin surfaces:

• The interface is bilingual (English / العربية) and right-to-left aware, and dates are shown as YYYY-MM-DD.
• Consequential actions are audited, not silently deleted. Everything in this manual — creating a user, recording a payment, flipping the AI switch, granting support access — leaves a trail on your organization's audit log.
• No silent cross-org data sharing. The pool, the AI opt-in, and support access are all built so nothing about a candidate or your tenant ever leaves without an explicit, recorded decision by you. That promise is the product; these controls are how you keep it.

Your admin controls live under Settings in the sidebar. Let's walk them in the order you'll first need them.

Your dashboard — the organisation health panel

You land on the same Dashboard as an HR manager — the pipeline headline and the "what needs you now" to-do cards described in the HR manager manual — but as admin you get one thing no one else does: an Organisation health panel across the top, the tenant-level signals you're accountable for, each linking to where you fix it:

• Subscription — your current standing in plain words: active with the days left in this term, lapsing soon (a countdown when the term is nearly up), payment past due, or lapsed. A lapsed subscription is what locks the shared talent pool, so this is the one to keep green. It links straight to Manage billing.
• User seats — how many staff accounts you've created but that haven't been activated yet (invited people who haven't set their password), or a clean "all seats activated." It links to Manage users.
• Talent pool — whether your organization's pool access is currently active or not entitled, mirroring your subscription standing.

Think of this panel as your account's vital signs: subscription current, everyone you invited actually onboarded, pool access where you expect it. The hiring work below it is the same as any HR manager's — read on for the controls that are yours alone.

Users — the people on your account

Open Settings → Users (settings/users). This is where you provision the staff who work hiring in your organization.

Creating a staff account

Add a colleague by email and give them a role. HeadHunter sets them a temporary password and asks them to choose their own the first time they sign in, so only they ever know it. The roles you can assign here are the four org-staff roles:

• Org admin — a peer to you, with these same account controls.
• HR manager — runs hiring end to end (see the HR manager manual).
• Recruiter — a focused screening role (see the recruiter manual).
• Compliance officer — records declarations and reference evidence.

A hiring manager is not created here. That role is an external, per-posting collaborator your HR managers invite directly from a shortlist — narrowly scoped to the one posting they're asked to weigh in on. You won't find it in this dropdown, and that's deliberate.

Changing roles and removing people

Change someone's role or deactivate an account they no longer need from the same screen. Two safety guards protect you from locking your organization out:

• You can't deactivate or demote the last active admin — someone must always hold the keys.
• You can't deactivate or remove yourself — so you never accidentally sign your own account out of existence.

Billing & the pool subscription

Open Settings → Billing (settings/billing). HeadHunter's billing is deliberately simple and offline: there is no online card gate. Your Waves contact collects payment in cash or via Bank of Khartoum (Bankak), and you record it here.

Recording a payment as a subscription period

When a payment is made, record it as a subscription period — the dates it covers. That's the single act that keeps your organization entitled. The panel shows you the derived access state so you always know exactly where you stand:

• Entitled — the subscription is active; your team can browse the shared pool.
• Lapsed — the last period has ended; pool access is locked until you record the next payment.
• Absent — no subscription on file yet.

What lapsing locks — and what it doesn't

The subscription gates the pool — the cross-organization talent sharing that is HeadHunter's moat. If it lapses, your HR managers and recruiters see a respectful lock notice on the Pool screen rather than a broken page, and referrals pause until you renew. Nothing else stops: posting, parsing, scoring, shortlisting, rejecting, compliance, and reports all keep working. Lapsing closes one door — the shared network — not the whole building.

Separately, when an HR manager publishes a posting they see a value gate — a clear note about what publishing involves under your plan. That gate reads the same billing state you manage here, which is why publishing sometimes points them back to you.

AI opt-in — the semantic-match consent switch

Open Settings → AI (settings/ai). This one switch governs whether HeadHunter's semantic match recall aid is available to your team — and, more importantly, whether any candidate's CV content is ever sent to an AI model for that check.

• It is OFF by default. Nothing about a candidate leaves the system until you deliberately turn it on. That's the privacy promise made concrete: silence is the default state.
• What turning it on does. Semantic match looks for possible matches the keyword rubric might have missed and surfaces them in a separate "possible matches" section of an applicant's breakdown. It never changes a score or a ranking — it's a recall aid so a good candidate isn't overlooked, not a re-ranker.
• The disclosure. The panel carries the privacy and DPIA (data protection impact assessment) disclosure of exactly what is processed and why. Read it before you switch on — this is a real data-processing decision, and toggling it either way is audited.

If your team asks "why don't I see possible matches?", the answer is almost always that this switch is off — nothing is broken.

Support access — time-boxed, break-glass help

Open Settings → Support access (settings/support-access). Occasionally a Waves platform admin may need to look at your real data to help you with a problem. This screen is how you — and only you — let that happen, on your terms.

• You grant a named platform admin temporary, read-only access to your tenant.
• You can see every active and past grant, and revoke instantly at any time.
• Access is never standing and never silent: it's always time-boxed, always tied to a person, and both the grant and the revocation are written to your own audit log (as well as the operator side).

This is the "no silent cross-org sharing" promise applied to support itself. Nobody at Waves sees your candidates' data unless you open this door, and you can close it in one click.

Audit retention

Your organization's Audit trail (the read-only record of decisions, consent, comms, and stage changes) is visible to your HR managers and compliance officers, who can view and export it. But how long that trail is kept — the retention policy — is an admin-only control, set on the Audit page itself. HR managers see and export the trail; you decide how long it lives.

Set a retention window that matches your donors' and your own record-keeping obligations. Because HeadHunter audits rather than deletes, this policy is the honest, deliberate answer to "how long do you hold our hiring records?".

Training console

Open Settings → Training (settings/training). This is an off-wedge growth surface — not part of core hiring — that lets your organization publish learning content.

Author courses and their lessons, then publish them to your organization's public learning catalogue at /learn/<your-slug>. Once a course is published, the console shows you the public link to share. HR managers can author here too; it's kept deliberately separate from the hiring product — it manages public content, not candidates or postings — so nothing you publish ever touches a candidate record.

Treat this as optional capacity-building for your community, not a step in a hiring run.

The candidate realm and your organization

HeadHunter now has a candidate realm: job-seekers can create their own HeadHunter accounts. There's no admin control for you here — but as the org admin who owns your organization's privacy story, it's worth knowing exactly how it relates to your tenant, because it's the same promise you enforce everywhere else, seen from the other side:

• A candidate's account is global and self-controlled — your organization cannot see it. People build a profile and CV that belong to them, not to any org. You have no window into it.
• Your org sees a candidate only when they apply. An authenticated application arrives through the same intake and consent path as any public apply — same parsing, same dedupe, the same candidate record. The only difference is behind the scenes: the application is optionally linked to the person's account so they can track its status themselves. From your team's side it screens exactly like any other applicant.
• Your published postings also appear on the aggregated cross-org board /jobs, alongside your own branded public page — "every open job in one place," which is where most candidates will find your roles.

This is "no silent cross-org sharing" stated from your side: candidates own their data, you see it only when they choose to apply, and consent rides along with the application. For what the job-seeker actually experiences, point them at the candidate guide.

You can also do everything an HR manager can

Beyond these admin controls, your account carries the full HR manager surface: posting jobs, screening applicants, building shortlists, rejecting respectfully, compliance and finalizing, interviews, the pool, and reports. Rather than repeat it here, read the HR manager manual — every flow it describes is available to you.

Quick reference

Your job as admin is to keep the account healthy and the privacy promises honest: the right people with the right roles, the subscription current, AI on only if you've chosen it, and support access closed unless you've deliberately opened it. Everything else is hiring — and you can do all of that too.