Skip to content

Allocation rules

What it is

Allocation rules are how ManpowerIQ decides, for each open slot, who is eligible and who is the best fit. There are two kinds: hard rules that can disqualify a candidate, and soft rules that score the survivors. Together they turn "fill this demand" into a ranked, explainable choice.

Why it exists

Choosing who works where is a constrained, repeated decision: certifications must be valid, leave and rest respected, hour limits honoured — and, among everyone who qualifies, the best and fairest pick made. Encoding that as rules makes the decision consistent, fast, and auditable, and lets each business unit tune it.

Key concepts & terms

  • Candidate — one combination of employee × demand line × date being evaluated.
  • Hard rule — a gate: if it fails, the candidate is ineligible and evaluation stops.
  • Soft rule — a scorer: it returns a score from 0 to 100 and never blocks.
  • Weighted score — the soft scores blended by weight into a single ranking number.
  • Rule set — the collection of rules in force; each business unit has one default set.
  • Scope — limits a rule to a department, terminal, or employee group.
  • Effective window — optional from/until dates during which a rule applies.
  • Snapshot — a per-run, pre-built copy of the data the rules need, so evaluation is fast (see Rosters & allocation runs).

How it works

For each candidate, the engine runs the active rule set in two phases:

flowchart TD
  A["Candidate: employee × demand line × date"] --> B["Hard rules, in severity order"]
  B -->|any rule fails hard| X["Ineligible — stop here, total score 0"]
  B -->|all pass| C["Soft rules — each returns a score 0–100"]
  C --> D["Weighted average of the soft scores"]
  D --> E["Eligible candidate, ranked by total score"]
  1. Hard rules first. They run in severity order, and the first hard failure short-circuits the whole evaluation — the remaining rules don't run, the candidate is ineligible, and the score is 0.
  2. Soft rules next. Each scores the candidate 0–100; the engine blends them into one weighted-average ranking score. Soft rules never make a candidate ineligible.

The hard rules are: certification expiry, leave conflict, hour limit, rest hours, double-booking, cross-pool eligibility, and maximum consecutive days. The soft rules are: skill priority, terminal priority, working-hours priority, the three equalization rules (off-day, overtime, shift-time), and an overtime-window steer.

An important correction. Every one of those hard rules and every soft rule is live and evaluates real data. Older design notes that say "only certification expiry is real and the others are stubs" describe an early build stage — the stubs were replaced. The only non-evaluating placeholder is an internal test rule that never runs in production.

Every rule reads the per-run snapshot first for speed, and only falls back to a live database query when the snapshot doesn't cover the date — both paths share the same logic so they can't diverge.

The default rule set (ARS_DEFAULT) — 7 hard + 7 soft rules, all live.

A candidate's per-rule hard-rule evaluation — the admin/debug view; a Planner does not see these reason rows (finding F6).

Rules & what's enforced

  • Hard failure is a hard stop. The first hard rule that fails ends evaluation; the candidate is ineligible with score 0.
  • Soft rules only rank, never block.
  • Scope and effective window can switch a rule off for a given candidate or date (it is simply skipped).
  • A broken rule can't kill a run. If a rule errors, that single result is marked as an error and the run continues.
  • Each business unit has exactly one default rule set.

What's live vs planned

  • Live: the engine, all 7 hard and all 7 soft rules, severity ordering and short-circuit, weighted soft scoring, rule sets, scopes, effective windows, and per-run execution logging.
  • Nuance to know: the three equalization soft rules score fully only when a run's snapshot is populated; outside a run they return a neutral score. They still never block. See Equalization & fairness.
  • A couple of parameters are accepted but not yet wired (for example, a "block if cross-terminal" toggle on the terminal-priority rule) — they're read but currently have no effect.
  • Reasoning is recorded but only partly shown. The engine records a reason for every hard pass/fail and a score for every soft rule, but the UI surfaces hard-fail reasons only in the admin/debug candidate view — normal users see the outcome, not the full reasoning. See Rosters & allocation runs (findings F6/F8).