Skip to content

Overview — What is ManpowerIQ

What it is

ManpowerIQ is a workforce rostering platform for ports and terminals. It takes the labour demand of a terminal — how many people, with which skills, are needed on each shift — and builds rosters that assign the right employees to the right places, automatically, while respecting certifications, leave, working-hour limits, and fairness.

It is multi-tenant: each operating company (a business unit) sees only its own data, kept apart at three independent layers. What any one person can see and do is governed by role-based access.

Why it exists

Port labour is hard to plan by hand. Demand swings shift to shift, employees carry different skills and certifications, some are on leave, hour limits and rest rules apply, and the work should be shared fairly. A spreadsheet cannot enforce those constraints at scale or explain why a given person was or wasn't chosen. ManpowerIQ makes the demand explicit, runs every candidate through a transparent set of rules, and produces a roster you can review, adjust, approve, and publish — with an audit trail behind the decisions that matter.

Key concepts & terms

Each term below has its own concept page.

  • Business unit (BU) — a tenant: one operating company. All data is scoped to a BU; you only see your own.
  • Terminal → Department → Node — the org hierarchy a BU is divided into. A node is the smallest unit work is planned against.
  • Pool — a group employees belong to; pools can lend staff to one another under rules (cross-pooling).
  • Employees & skills and certifications — the workforce and what each person is qualified and certified to do.
  • Shifts & calendars — when people work; shift templates and patterns, working days, holidays, and Ramadan/seasonal hour changes.
  • Demand plan — the stated need (headcount by node, shift, and day) that a roster must meet.
  • Allocation rules — the hard rules that can disqualify a candidate and the soft rules that score the remaining candidates.
  • Allocation run / roster — an execution of the rules against a demand plan, producing proposed assignments you then review, approve, and publish.
  • Equalization — the fairness layer that spreads off-days, overtime, and shift types evenly across a cohort.

How it works

The heart of the product is a pipeline:

Demand → Allocation rules → Run → Review → Publish.

  1. Planners build a demand plan: how many people, with which skills, are needed per node, shift, and day.
  2. An allocation run evaluates every eligible employee against the rules. Hard rules (certification, leave, hour limits, rest, double-booking, pool eligibility, consecutive-days) can disqualify a candidate outright; the run stops scoring a candidate the moment one hard rule fails. Soft rules then score the survivors on skill match, terminal priority, working-hours and fairness, producing a ranked choice.
  3. The run yields proposed assignments. A planner reviews them, then locks and publishes the roster.

Around that pipeline sit the foundations: the employee, skill, and certification records that say who can do what; the calendars and shift definitions that say when; leave and attendance; and the reports and dashboard that show coverage and outcomes. Access to all of it is mediated by roles and permissions, and your data is isolated to your business unit.

Rules & what's enforced

  • Tenant isolation is enforced, not advisory: every read is filtered to your BU, every write is stamped and guarded, and the database itself blocks cross-tenant access.
  • Access is permission-checked on every protected action — what you can reach is determined by your roles. See Roles & permissions.
  • The allocation engine enforces hard rules that block, and applies soft rules that score. (Detailed on the Allocation rules concept page.)

What's live vs planned

ManpowerIQ is largely built. The honest status, drawn from the verified fact base:

Live and usable

  • Foundation — multi-tenancy, roles & permissions, audit
  • Employees & the workforce — managed today via Excel import (no in-app create/edit screen yet)
  • Skills & certifications — catalogs are managed in-app; the per-employee skill matrix is read-only today
  • Calendars & shifts
  • Demand planning
  • The allocation rules engine — all hard and soft rules are live (not "cert-expiry only")
  • Allocation runs / roster generation
  • Roster approval & publish — single-step approval (multi-step approval chains are planned)
  • Leave management — requests and a two-step approval flow (there is no leave-type taxonomy yet)
  • Attendance & actuals — sourced from Excel import, not a device/clock feed
  • Pools & cross-pooling — directional lending between pools
  • Equalization / fairness — live when an allocation run's snapshot is populated

Partial

  • Approval matrix — it resolves the right approver from real data, but is not yet wired into a live approval flow
  • Reports & dashboard — four reports plus a manager tile dashboard; no charts anywhere, and the dashboard refreshes on a manual button (no auto-refresh)
  • Notifications — only a polled pending-count bell; there is no backend notification system
  • Org-structure & reference data — Terminals, Node Types, Pools (and a set of lookups) have full admin screens; Departments and Nodes are read-only
  • Mobile — a scaffold only

Planned (not built)

  • Rotations
  • Training & early release (some early-release config scaffolding exists, but no working request flow)
  • External integrations (HR/SAP, TOS, payroll)

The status list above is the source of truth. Where this guide ever seems to promise more than the status says, the status wins.