Workforce Management

This is the very first table a candidate's name ever appears in — a running roster of everyone who has cleared interview, before any of them exist as a full proctor record. Each row carries the email, vendor, work type and panel notes captured at intake, plus a live Form Status (Not Sent / Sent) and a one-click Send Form / Re-send Form action for the onboarding link.

Two intake paths feed this table: adding candidates one at a time, or Import CSV for bringing in a whole batch from a spreadsheet at once — both land in the exact same list, with the exact same per-row actions.

A second, separate way into the pipeline — for proctors whose personal details are already known internally and don't need the candidate to self-register. The Individual tab is a full profile form (name, Aadhaar, DOB, gender, type, vendor, contact details, address, notes) that creates a proctor record immediately, skipping the Onboarding Form step entirely. BGV is explicitly not required to use this form.

Bulk Onboard mirrors the same idea at scale: download a CSV template, fill in as many rows as needed, and upload it back to create many proctor records in one pass.

This is command central for everyone currently moving through the pipeline. Beyond the status and pipeline-stage columns already covered in the Onboarding Journey, three things make this table genuinely usable at scale:

• A real filter builder — Status, Vendor, Type and Documents Status, added on demand as removable criteria rather than four permanently-visible dropdowns competing for space.
• Bulk actions — select any number of rows and a floating toolbar appears with Send Docs, Verify and Activate, each one automatically limited to only the people who actually qualify right now.
• Inline editing — the pencil icon on any row opens a full edit panel without ever leaving the list.

Every bulk send is tracked as its own job, not fired blind. Bulk Activity groups recent sends by type and shows a live sent/processing/failed count per job — and drilling into any one of them shows exactly who it reached, when, and with what result.

A dedicated, always-current queue of who is still missing a background-verification document, separate from a Pending vs Uploaded view and a vendor filter — so an admin never has to scan the entire workforce table to find who's at risk of going overdue.

Offboarding is triggered from an active proctor's own record (the Offboard action in their drawer) and lands them here with a reason attached — this page is the permanent record of who left and why, filterable by vendor and exportable.

A second tab, Re-onboard History, tracks the opposite movement: someone who left and was later brought back in, so that history isn't lost just because a record temporarily left the active list.