Two different things sit at the bottom of the taxonomy, and the whole hiring and growth stack depends on telling them apart. A Job Description is the definition of a job — its name, its competencies, its target headcount, its pay band, its Saudization policy. A Position is a requisition: it sits under that Job Description, placed in the org structure, with its own job description text, hiring pathway, pipeline and candidates — and it can now hold more than one seat at once, up to its capacity. See Seat capacity and openings below.

The model

The chain is Sector → Sub-sector → Job family → Job Description → Position → employee. One Job Description carries many Positions; one Position can now be filled by more than one employee at once, up to its capacity (and by many people over its life). An employee's place in the org chart comes through their Position — the Position holds the org unit, so there is one placement axis, not two.

Job Descriptions

Where to find it, and who can do what

/{slug}/app/job-description — sidebar Structure → Job Descriptions.

The table view

Job Descriptions are shown as a single table with one header row, with sub-sectors and job families acting as collapsible group rows inside it — so a large structure stays scannable while the columns stay aligned all the way down.

1. Sub-sector — the outer group row. Click to fold the whole sub-sector away; a badge shows how many Job Descriptions it holds.
2. Job family — the inner group row, nested under its sub-sector. Each family row carries an inline + button that opens the create form pre-filled with that sub-sector and family, so you can add a Job Description without leaving the table.

Both levels start expanded. Job Description rows are numbered within their family and sit directly beneath it.

The columns

Editors also get a trailing ⋮ column on every row — see Duplicating a Job Description.

Job Descriptions whose sub-sector is no longer part of your workspace selection — and title-only stubs with no taxonomy at all — are pulled out into a strongly highlighted Without sub-sector band pinned to the top of the table, so they are impossible to miss and obviously need triage.

Three tiers of headcount

Three different numbers now describe how big a job should be, and each answers a different question:

These three numbers are set and read on the Job Description's edit form and its Positions (established is the number hiring can actually act on today, desired is where you're headed); the Job Descriptions list itself no longer carries a Headcount column — it now shows the role's Salary grade instead.

Search and reordering

The search box filters Job Description rows only; families and sub-sectors with no match disappear, and the grouping never re-sorts itself under you.

HR Administrators can drag the listing into the order their organisation actually thinks in. Each sub-sector and job-family row has a drag handle (⋮⋮):

• Sub-sectors reorder against the whole table; the order is saved per workspace.
• Job families reorder within their sub-sector. Because one family can belong to several sub-sectors, its position is remembered separately in each — the same family can sit high in one section and low in another. You can only drop a family inside its own section.

The order sticks for everyone in the workspace; anything you have not reordered stays alphabetical. Drag handles are hidden while a search is active — clear the search to rearrange.

Creating a Job Description

New job description in the header (or the + on a job-family row) opens a two-step form. (Editing an existing Job Description uses a different, unified layout — see Editing an existing Job Description below — but collects the same fields, so the field-by-field notes here apply to both.)

Step 1 — Taxonomy & source settles where the Job Description lives and where its name comes from. Step 2 — Job Description details collects the Job Description itself. The split is deliberate: every choice on step 1 resets fields on step 2, so it is not worth filling them before step 1 is settled.

The step header doubles as navigation — click a step to jump back to it. Next stays disabled until step 1 is complete.

Step 1 — Taxonomy & source

Sub-sector. Pick from the sub-sectors your workspace selected during onboarding. Required. Changing it clears the job family and the competency selection.

Job family. Pick from the families linked to that sub-sector. Required. Choosing a family pre-selects every competency your workspace has enabled on that family, each at its default level — a Job Description inherits its family's competency set and you subtract from it rather than building from nothing. On a wide screen the two pickers sit side by side.

Job Description source — where the name comes from:

• From the Saudi standard (the default for a new Job Description) — pick from the Saudi Standard Classification of Occupations (SSCO). The list is scoped to the job family you chose above, so you only see occupations that genuinely belong under it, ordered strongest match first and tagged Strong match, Possible match or Review. Search by Arabic name, English name, or the six-digit SSCO code. The one you pick is highlighted and tagged Selected, and is repeated in a summary line above the list so your choice stays visible after you scroll or search again. Picking one fills both name fields and both descriptions on step 2, and you can still edit all of them — the English name is a translation of an Arabic-only standard, and your own job titles are yours to set. A Job Description your workspace already holds appears greyed out as Already added and cannot be added twice.
• Create new — write the job yourself on step 2. Use the bilingual autofill buttons to draft the other language (and the description) with AI from the one you typed.

(On the create form the source lives on step 1; when editing it lives inside the collapsed Classification & source summary — the fields and behaviour are identical.)

In standard mode you must pick an occupation before Next — unless the job family has none in the standard (or the list fails to load), in which case the form says so and lets you move on and name it yourself. (When editing, the same standard/new choice and picker live inside the collapsed Classification & source summary on the Overview section — see below.)

Job Descriptions adopted from the standard keep a link back to their SSCO code; ones you write yourself do not. When you edit a Job Description later, its source (standard vs. hand-written) reopens in whichever mode produced it.

Where the description comes from. SSCO itself publishes codes and Arabic titles only — no descriptions — so the text you get is written by Jadiroon against the classification's own structure, at the level of the four-digit unit group every occupation belongs to. Occupations inside one unit group are the same job under different titles, so they share a definition, except where a unit group is an explicit catch-all ("not elsewhere classified") and its occupations genuinely differ — those carry their own line. The description is copied into your Job Description once, at the moment you adopt it. Editing it afterwards changes your copy only, and a later revision on our side will not reach back into a description you have made your own. Nothing is filled in if you have already written either description yourself.

Step 2 — Job Description details

Step 2 restates the chosen sub-sector · job family under its heading, then collects:

Job Description competencies

Still on step 2. Every competency your workspace enabled on the chosen job family starts ticked. Untick what doesn't apply to this particular job. Competencies are shown in two columns so the kind is never ambiguous:

• Technical competencies — the role-specific, hard competencies.
• General competencies — the transferable, behavioural competencies.

A single search box above both columns filters them at once, keeping the two lists separate. Each column's Select all / Clear acts on what is currently visible, so you can search, select all the matches, refine, and select again. Selected competencies float to the top of their column.

AI suggest competencies asks how many of each you want (defaults: 10 technical, 5 general, each capped at the size of the available pool) and confirms the AI cost, then opens a picker: the suggestions — pool picks and any invented New competencies — arrive pre-ticked, each with its reason and recommended level. Untick what you don't want, choose Add to or Replace your current selection with a radio, then confirm. Nothing changes until you do — Cancel discards the batch. Applied competencies carry a gold star and sort to the top. If the AI returns nothing you get a warning and your selection is left untouched.

Also suggest new competencies (a checkbox on the same panel, shown only if you can edit competencies) lets the AI go beyond the family's existing pool: when ticked it may invent competencies the family is missing, each proposed with a bilingual name and a full 1–5 (or 1–3) proficiency rubric, tagged New in the list. A new competency costs nothing until you act on it — it lives only in the editor. The moment you tick one and save the Job Description, it becomes a real competency in your workspace's library, linked to this sub-sector and job family (so it then appears in the pool for other Job Descriptions in that family), and attached to this Job Description at the level you set. New competencies you leave unticked are discarded. If an invented name already matches an existing competency you can see, that competency is reused instead of duplicated; if the name is already taken by another workspace it's skipped and you get a notice.

Required level

Ticking a competency reveals a compact − N + stepper where you set the required level for that competency in this Job Description. This is the target every gap analysis measures against (gap = current − required):

• Technical competencies score 1–5, defaulting to 3.
• General competencies score 1–3, defaulting to 2.

Raise it where mastery is critical, lower it where familiarity is enough. The value flows straight into gap calculations, development reports and readiness scores, and is shown after each competency on the detail page (e.g. SQL · 4/5).

What the server enforces

• The sub-sector must be one your workspace selected, under your workspace's sector.
• The job family must be visible to your workspace and genuinely linked to that sub-sector.
• An SSCO code must be reachable from the chosen job family, and the same standard occupation cannot be added twice in one workspace — the second attempt is rejected with a clear conflict message.
• Competencies must come from your workspace's selection on that job family, not from the global catalogue. AI-invented "new" competencies are the one way to add to that selection from here: they require the org.skills.edit permission, are created inside your workspace, and are joined to the family's selection as part of the save — so by the time the Job Description's competency links are written they satisfy this same rule.

Editing an existing Job Description

Editing does not reuse the create wizard. Edit opens a unified editor that puts everything about the Job Description — its core fields and its full Job Description card — into one screen with a single side rail of sections, instead of the old layout that stacked a two-step form on top of a separate tabbed card block.

A sticky header keeps the Job Description's title, its sub-sector · job family context, and one Save in view wherever you scroll. The rail is grouped in two:

• Core — Overview (job title, job type, purpose), Hiring & pay (default pay grade, desired headcount, Saudization, work location), and Competencies (the same inherited-and-subtract competency matrix and required-level steppers described above). These are the plain Job Description columns.
• JD card — Responsibilities, Level evaluation, KPIs, Contacts, Qualifications, and Authorities: the MOMH card's structured child sections. These structured sections are now fillable in both flows — creating and editing. On create, the whole Job Description (core columns and the full card) is authored on one screen and committed together in a single atomic save, so nothing is locked behind a first save.

One save for everything. Every change you make — in any section, Core or JD card — is held locally in the editor and is not written to the server until you click the header's Save. There are no per-section or per-row save buttons and nothing auto-saves; the whole Job Description commits together, in one step.

The Save dialog — version + note. Clicking Save opens a short dialog with a free-form version label (pre-filled with the Job Description's current version — change it or keep it as is) and an optional note describing what changed. Confirm, and the entire card is written at once. Because the draft lives only in the editor until then, leaving or refreshing the page with unsaved changes warns you first.

Because the taxonomy and source rarely change once a Job Description exists, Classification & source is collapsed at the top of Overview into a one-line read-only summary (sub-sector · job family · source) with a Change toggle that reveals the same sub-sector / job family pickers and standard-vs-new source picker from step 1 only when you need them.

Every section stays loaded as you move between them, so a half-typed responsibility or an unsaved change is never lost when you switch sections.

The Job Description detail page

The header shows the name, sub-sector · job family, and badges for Archived / Open to hire / Closed / Placeholder, plus a View in org chart action.

Below it, in order:

1. Actions — Edit and Archive for anyone with edit rights; Edit competencies alone for Talent Acquisition; Restore on an archived Job Description.
2. Placeholder notice — a warning panel with a Complete this job description shortcut, for editors.
3. Job Description info — Description, Technical competencies (as name · required/5), General competencies (name · required/3).
4. Job description — the most recent non-empty description written on any of this Job Description's Positions. The description is authored on the Position but it describes the Job Description, so it is surfaced here too, and stays visible even when nothing is open for hiring. If no Position has a description yet, the panel is hidden. The structured eight-section card (purpose, responsibilities, level evaluation, KPIs, contacts, qualifications, delegated authorities) is a separate, richer record authored on the Job Description's own Edit form — see The Job Description card for what each section means.
5. Positions — every non-archived requisition under this Job Description with its Open/Closed badge and a Manage link, plus a Create position button for Talent Acquisition. Hidden on archived and placeholder Job Descriptions.

Placeholders

A Job Description is a placeholder exactly when it is missing a sub-sector, a job family, or both. That is the only rule.

Placeholders arise in two ways: title-only stubs carried over from earlier workspaces, and Job Descriptions you wrote yourself whose job family you later deselected in onboarding — rather than delete your work, the platform parks them as taxonomy-less stubs so you can re-file them. Job Descriptions adopted from the SSCO standard are removed cleanly instead.

A placeholder cannot be opened for hiring, cannot use the competencies-only editor, and does not appear in the Job Description picker when creating a Position. Linking it to a sub-sector and a job family completes it — and it inherits that family's default competency set at the same moment.

Duplicating a Job Description

Large structures repeat themselves — the same nursing or inspection job appears again and again with one field different. Rather than re-run the two-step form, open the ⋮ menu on any Job Description row and choose Duplicate job description. You land on the copy's edit form straight away, ready to change what differs.

The copy is named <original> (copy) / <الأصل> (نسخة) so it is unmistakable in a long list — rename it as your first edit.

The competency set is the point: it is the part that takes longest to curate and the part gap analysis measures against.

The action needs the Edit job descriptions permission — the same one that gates renaming and re-pricing — so HR Administrators and Workforce Architects see it and Talent Acquisition does not. The menu is simply hidden for anyone else, and the server refuses the request regardless of what the browser sends.

Archiving and restoring

Archive takes a Job Description out of the active list. It is not a delete, and it cascades: every open Position under the Job Description is closed in the same step, and their open pipelines are closed with them. The confirmation dialog says so explicitly when the Job Description has live hiring.

Archived in the header opens the archived list (with a count badge), where each entry shows when it was archived and offers View and Restore. Restoring returns the Job Description to the active list — hiring stays closed; you reopen Positions explicitly when you're ready.

Positions

Where to find it, and who can do what

/{slug}/app/positions — sidebar Structure → Positions.

Viewing is open to HR Administrators, Workforce Architects, Talent Acquisition and Line Managers. Creating, opening, closing, archiving and restoring a Position is Talent Acquisition's (and the HR Administrator's) permission — a Workforce Architect can define Job Descriptions all day but cannot open one for hiring. That split is deliberate: structure and recruitment are separate jobs.

Seat capacity and openings

A Position is no longer strictly one seat. Its capacity is the number of established, interchangeable seats it holds within its single org unit — most Positions still carry a capacity of 1, but a Position representing several identical seats in one unit (say, six inspectors in one department) can be created with capacity 6 instead of six separate Positions.

• Openings = capacity − filled, clamped at zero. Filled only counts people with employee status currently assigned to the Position — pending candidates, invitations and referrals never count against it.
• Hiring happens at the Position level, not per individual seat: one pipeline serves the whole Position, and an offer fills whichever opening is available. There's no way to target "seat 3 of 6" specifically.
• Assigning an employee to a full Position is hard-blocked on every interactive path — the org-structure assign, add-employee/edit, offer acceptance, and the hiring pipeline's Hire action all refuse the assignment once filled reaches capacity: move or offboard someone first, or raise the capacity. Bulk CSV / AI import does not yet enforce this cap (a known follow-up) — an import can still push a Position over capacity.
• The Hired button in the table below opens every current occupant of the Position, not just one.

Capacity is set as the Seats field when a Position is created or edited from the org structure. It defaults to 1 and can never be lowered below the number of employees currently filling the Position. The New position wizard on this page always creates a Position with capacity 1; raise it afterwards from the org structure if the seat needs to hold more than one person.

The table view

Filters, search and sort

• Job Description filter — narrows the table to one Job Description. Only Job Descriptions that actually have Positions appear in it.
• Link to org structure — All / Linked to a unit / Not linked to any unit, each with a live count. When Positions are unplaced, an amber banner offers Show them (jumps straight to the filter) or Dismiss.
• Search across the Position title, its Job Description, and the job family.
• Sort by — Default (status, then newest), Title (A→Z / Z→A), Applicants (most / fewest first), and — for viewers who can see people — Hired (most / fewest first).

The columns

Viewers who can edit positions also get a trailing ⋮ column — see Duplicating a Position.

The table body has a sticky header and is paginated at 25 rows per page, with a 1–25 of N range and Prev/Next.

Creating a Position

New position in the header, or Create position from a Job Description's detail page, opens a two-step wizard — mirroring how Job Descriptions are created. Step 1 — Job Description & source settles which Job Description the seat belongs to and where its details come from; Step 2 — Position details collects the seat itself, pre-filled if you started from the library. The step header doubles as navigation, and Next stays disabled until step 1 is settled.

Step 1 — Job Description & source

1. Job Description — a searchable list (both languages, and by job family). Required. Only complete, non-archived Job Descriptions appear — a placeholder must be finished first, and the form links you there.

   Filter job descriptions (optional) sits above the picker: a sub-sector and a job family. Both are empty by default and the picker shows every job description — set either one, or both, to narrow it, and the line underneath tells you how many of your job descriptions are still showing. The two filters constrain each other, so you only ever see values that still have job descriptions behind them and no combination can empty the list. Each filter offers All sub-sectors / All job families to undo it, and Clear filters resets both. If a filter hides the job description you had already selected, the selection is dropped (along with anything a predefined position had pre-filled) so a hidden job description can never drive step 2.

2. Source — where the new seat's details come from:

   • From the position library (the default) — the predefined position library narrowed to the job description you picked, matched by its exact SSCO code. Search it, and each entry shows its compliance badges (Saudis-only, licence, quota…). Pick one to pre-fill both job titles, attach its standard roles, and seed the job description from its summary. If that job description has no predefined positions — or you wrote it from scratch so it carries no SSCO code — the form says so and lets you continue from scratch.
   • Create from scratch — define everything yourself on step 2.

   Switching to Create from scratch, or changing the job description, clears anything a predefined position pre-filled.

Step 2 — Position details

Step 2 restates the chosen job description (and, when you started from one, the predefined position) with a Change link back to step 1, then collects:

3. Org unit (optional) — which department or section the seat sits in, shown with its type and full parent path. Picking one places the Position in the org structure immediately, so it shows as placed and its workload can be measured right away. Leave it empty and place it later; it will show up under the Not linked to any unit filter until you do.
4. Job title (English) and Job title (Arabic) — at least one is required. This is the outward-facing title; leave one blank and the Job Description name is used for that language. A predefined position pre-fills both, and you can still edit them.
5. Job description (required to open) — write it or press Generate with AI to draft a bilingual structured description (summary, responsibilities, requirements, preferred). The generator reuses the linked Job Description's own content — it keeps the JD's authored purpose, its standard responsibilities and its qualifications largely as they are (light polish at most) and only generates the parts the JD leaves empty (such as preferred qualifications) plus any missing language, drawing on the sector, Saudization setting and competencies. So it builds on the real definition instead of rewriting it. AI generation asks you to confirm the cost first. At least one language is now required to open a Position; you can leave it empty only when you Save as placeholder and complete it later.
6. Hiring pathway — required. Three cards:
   • Internal only — existing employees only; there is no public page.
   • Internal first — internal now, opening externally automatically after your workspace's internal-first window (14 days unless you changed it in hiring configuration).
   • External — open to everyone immediately.

Submitting creates the Position with hiring Open, creates its pipeline, and lands you on the Position page. Starting from a predefined position only pre-fills the form — the seat you create is an ordinary Position and stays fully editable.

Editing a Position

Edit on the Position page revises the job titles and the job description — the outward-facing content. At least one title must remain.

The Job Description, the org unit and the hiring pathway are not editable here: the Job Description is the Position's identity, the org unit is changed from the org structure, and the pathway is changed with the Make external action. There is no AI generate button on the edit form; generate on create, then refine by hand.

Archived Positions are read-only, so Edit is hidden once a Position is archived.

Duplicating a Position

Ministries and giga-projects run dozens of near-identical seats under one Job Description. The ⋮ menu on any Position row carries Duplicate position, which creates the next one in a single click and lands you on it, ready to edit.

The copy is titled <original> (copy) / <الأصل> (نسخة) in both languages. A Position that had no title of its own gets one seeded from its Job Description name plus the suffix — otherwise the copy would be indistinguishable from the original in a several-hundred-row list.

Workload tasks are carried over: reusing the workload model is most of the reason to duplicate a seat, and the copy would otherwise measure as zero effort. Adjust or delete them on the copy as needed.

Duplicating needs the Edit positions permission (the Workforce Architect's structural permission), not the hiring permission. A Workforce Architect who duplicates therefore lands on the new Position's detail page rather than its editor, because revising the outward-facing title and description belongs to Talent Acquisition.

The Position detail page

The header shows the title, Job Description · job family, and an Open / Closed / Archived badge. Two actions can appear:

• Edit — unless archived.
• Hiring board — only while the Position is open and has a pipeline. It jumps straight to that Position's Kanban pipeline, with no detour through the Hire dashboard.

Job details lists the Job Description (linked), the job family, the status, the hiring pathway, and the job description.

Lifecycle actions

Each is confirmed before it runs:

Archived Positions drop off the active list. Archived in the list header opens them with a count badge; Restore brings one back — with hiring closed, so you reopen it deliberately.

The public posting card

Shown on an open, non-archived Position that has a pathway:

• Internal only — a stub explaining there is no public page.
• Internal first, before the window closes — "Internal-only until date", plus Make public now for Talent Acquisition.
• External (or internal-first past its window) — the public URL with Open and Copy, an AI-drafted share post, and Copy text / WhatsApp / LinkedIn buttons.

Positions created from the org structure

The Positions list is the hiring view of the entity. The same rows are also created and managed as seats from the org structure — title, Job Description, org unit and a Seats field (the Position's capacity, defaulting to 1), with no hiring fields — including a bulk Excel/AI import. A Position's capacity can never be lowered below its current filled count. A seat that currently has an employee assigned cannot be deleted; move the person first.

You can add a seat from either a unit's row in the tree view or its card in the graph view — clicking a graph box opens the unit's detail with the same + Position action. In that dialog the Job Description field is a searchable picker (type to filter the workspace's job descriptions), and an optional Pay scale → Grade → Step picker sets the seat's base pay — the same Scale → Grade → Step model as the New position wizard. Selecting a job description prefills the pay scale and grade from that job description's defaults (its default grade); the values are only defaults — clear or change them per seat. Leaving the pay scale empty falls back to the job description's default pay grade; a scale and grade without a step show the grade's whole range, and pinning a step narrows it to that step's base salary.

The predefined position library

The product ships a global library of predefined positions — a curated set of Saudi-labour-market jobs, each mapped to one official occupation in the Saudi Standard Classification of Occupations (التصنيف السعودي الموحد للمهن / SSCO). It exists so you can start from a recognised job instead of a blank form.

Each predefined position carries:

• An SSCO occupation link (sscoCode) — the official Arabic occupation name and its place in the national classification, so the job is standard rather than invented.
• A job family — resolved through the SSCO → job-family crosswalk, so the position lands in the right part of the taxonomy.
• Suggested defaults — a Saudization policy default and (where known) a salary-band hint, copied onto your Job Description when you adopt the position.

Compliance signals

Because Saudi labour regulation restricts who may fill certain jobs, each predefined position carries structured compliance flags — surfaced as badges so a wrong hire is caught before it happens:

Using a predefined position

You reach the library from the New position wizard. On step 1 you pick the Job Description, then choose From the position library — the wizard shows the predefined positions whose SSCO code matches that job. Picking one pre-fills the seat: both job titles and the job description (seeded from the position's summary, and only where you haven't written one). The compliance badges ride along so a restricted hire is caught up front.

Because you pick the Job Description first, the predefined position never creates or changes a Job Description — it only fills in the seat under one that already exists. Everything it pre-fills stays editable, and your hand-made job descriptions and positions are never touched. A Job Description you wrote from scratch (no SSCO code) simply has no library matches; create its seat from scratch.

Related

• The Job Description card — the eight-section standard card authored on the Job Description: purpose, responsibilities, level evaluation, KPIs, contacts, qualifications and delegated authorities.
• Taxonomy — sectors, sub-sectors, job families and their mandates.
• Saudization — the other policy that lives on a Job Description.
• Pay scales — a Job Description's default pay grade is its salary range; link a Position to its own grade and step to override that default and compute its base pay directly.
• Opening a position to applications — the hiring-side walkthrough.

Next

Hiring configuration — the internal-first window, the auto-advance threshold and email templates — is covered next.