Internal mobility surfaces Job Descriptions an employee could move into, ranked by how well they fit — with their own line of work weighted most heavily. It is the surface to use when an employee wants a change, and the question is "where in the organisation could this person plug in and be effective?"
A Job Description appears in mobility results when it has at least one Position the employee could move into. A Position counts as a destination when it is open to hire (an active requisition) or vacant (a seat with no current incumbent) — mobility only surfaces moves an employee could actually make right now.
A target filter at the top of the table controls which positions are considered: Open + vacant (the default, the widest set), Open only (active requisitions), or Vacant only (unoccupied seats). Switching it re-ranks every employee's matches against the chosen pool. When the chosen pool has no positions at all — for example a fully-staffed workspace with no open requisitions — the table says so explicitly (and offers admins a shortcut to manage positions) instead of showing a bare "No matches" under every employee.
Where to find it
/{slug}/app/grow/mobility → pick a person, or pick a team to see all team members.
How matches are ranked
Mobility is gated to the employee's vertical of the org structure. Like succession and career paths, the candidate pool is driven by the org-structure hierarchy (the org-unit tree), not by the reporting relationship: only Job Descriptions found on Positions in the employee's own org unit, its ancestor units, or its descendant units are considered. A move to a job description outside that vertical is not surfaced. (An employee with no placed current position has no anchor in the tree, so no mobility candidates.)
Within that gated pool, scores are computed per Job Description (via its target Positions in the selected pool). For each employee, every in-vertical Job Description that currently has a target Position — open or vacant, per the target filter — except the one they currently hold, is scored 0–100 and the top three are shown. Job Descriptions with no target Position in the active pool are not scored. The score is a weighted blend of six factors, listed from the highest weight to the lowest:
- Same job family (highest). A Job Description in the employee's own job family is the strongest signal — their craft transfers directly. A software engineer's strongest mobility matches are other software-engineering Job Descriptions in different teams.
- Technical-competency fit (high). A graded match of the employee's competency profile against the Job Description's technical requirements. The more of the required technical competencies they already hold at the needed grade, the higher this term — partial credit, not all-or-nothing.
- Org-unit proximity (graded). How close the target job description's org unit sits to the employee's within their vertical of the structure — the same unit is the readiest move, and each step away (up or down the tree) counts a little less. This is the org-structure signal that replaces the old reporting-based bonus.
- General-competency fit (low). The same graded match against the Job Description's general (soft) competency requirements.
- Sub-sector proximity (low). A small boost when the target Job Description sits in the same sub-sector as the employee's current Job Description.
- Seniority guard (low). A proximity check that keeps Job Descriptions at a wildly different grade from surfacing as top moves; a comparable grade scores best.
A small Saudi-preference boost (+2) is also added when a Job Description prefers Saudi nationals and the employee is Saudi.
This differs from career paths in one important way: career paths is gated to higher-grade job descriptions in the org-structure vertical tree — a person's career-paths view only scores Job Descriptions above their own grade, found in their org unit or up to three ancestor units. Mobility uses the same org-structure gate but is direction-agnostic: it scores in-vertical Job Descriptions of any grade (up, down, or lateral) that currently have a target Position, led by their own job family and org-unit proximity.
Seeing why a score is what it is
Every match card is clickable. Selecting one opens a score breakdown that shows exactly how that percentage was reached — each factor and the points it contributed (e.g. job family 33/33, technical fit 12/28, org-unit proximity 7/10), with a bar for the graded factors. The org-proximity factor also notes how many steps away in the structure the target unit sits. For the technical and general factors it lists every required competency, the grade the Job Description needs, and the employee's current grade — so you can see which competency held the score back and which carried it. A competency the employee does not have on profile is shown as "not in profile". The points across all factors add up to the headline score.
This is the surface to open in a development conversation when someone asks "why is this only 48%?" — it turns the number into a concrete, per-competency development list.
Each match badge is colour-coded on the same scale as gap analysis: green for a strong match (75%+), amber for a partial one (50–74%), and red below 50% — so a row's top moves read at a glance before you open the breakdown.
Tuning the score (admin)
The default weighting is sensible, but every organisation values these factors differently — a craft-heavy team may want technical fit to dominate; a tightly-structured one may lean on org-unit proximity. An HR admin can retune the score per workspace from the Scoring button at the top of the mobility page (visible to admins only). The dialog lists all seven factors, each with:
- A weight — the points the factor contributes (e.g. raise job family from 38 to 45, or drop technical fit from 28 to 20).
- An include checkbox — uncheck a factor to remove it from the calculation entirely. A disabled factor scores no points and no longer appears in the breakdown dialog.
The included factors must total exactly 100 — the score is a percentage, so the weights have to add up to 100. The panel shows a live running total and the Save button stays disabled until you reach 100, telling you how much to add or remove. All seven factors share the same 100-point budget, including the Saudi-preference bonus; if you raise one factor you must take points from another, and if you disable a factor you redistribute its points across the rest. The default split is job family 33, technical 28, general 9, sub-sector 9, seniority 9, org-unit proximity 10, Saudi preference 2. Reset to defaults restores it. Changes take effect immediately: saving runs a live recalculation of the currently open employee's matches against the open jobs with the new weights, behind a "Recalculating matches…" overlay, so you see the effect of a weight change without reloading the page. The settings are workspace-scoped: one team's tuning never affects another's.
Use cases
- An employee wants to broaden. They are content in their current Job Description but want to do different work. Mobility shows where they could move while their compensation and seniority stay roughly constant.
- A team is reorganising. Some people will need to move; the mobility view shows where each affected person has a strong match within the organisation.
- Talent retention. An employee who feels stuck in their current Job Description is more likely to leave. Mobility surfaces alternatives that may keep them in the organisation.
How it surfaces alongside career paths
The Grow dashboard has both surfaces side by side. For any given employee, the career-paths view answers where could they grow up to? — a fit score against higher-grade Job Descriptions in their org-structure vertical tree — and the mobility view answers where could they move to? — a fit score against in-vertical Job Descriptions of any grade that currently have a target Position (open or vacant), led by their own job family and org-unit proximity. Both are anchored to the same org-structure tree, never to reporting lines.
A useful pattern: in a development conversation, look at career paths first (aspirational), then at mobility (immediately accessible). The two surfaces give the conversation more range than either alone.
What is excluded
- The employee's current Job Description. It is never shown back to them as a move — but other Job Descriptions in the same job family are, and rank highly.
- Job Descriptions with no target Position in the active pool. A Job Description is scored only when it has a Position that matches the selected target filter —
hiringStatusOPEN(open pool), no current incumbent (vacant pool), or either (open + vacant). Job Descriptions with no qualifying Position are skipped — mobility surfaces moves an employee could make now, not hypothetical openings. - Job Descriptions in
ARCHIVEDstatus. Already excluded from career paths; same here. - Job Descriptions where the employee is already the best internal match for the existing posting. If the Job Description is currently open and the platform thinks this person is the most likely internal candidate, it surfaces in Internal candidate rather than in Mobility.
- Saudi-only Job Descriptions for non-Saudi employees. If a Job Description has
saudiPriorityset toONLY, it is filtered out of the mobility surface for employees who are not Saudi nationals. The logic mirrors the public application form gate — the same rule that prevents non-Saudi candidates from applying externally also prevents the platform from surfacing those Job Descriptions as internal options for non-Saudi employees.
Next
Succession planning — the highest-stakes growth surface — is covered next.