Multi-Candidate Interview Scheduling for Recruiting Agencies: A Slate Workflow

Coordinate a candidate slate in eight steps

Use one client search with four candidates, a required hiring manager, two required interviewers, one optional observer, and a recruiting-agency owner. The client panel spans Google and Microsoft. Candidates provide bounded windows without connecting personal calendars. One panel calendar changes after three proposals exist.

1. 1

   Create the client lane and four candidate records

   Store a client lane with search ID, role, stage, interview format, duration, bounded campaign window, scheduling deadline, required panel roles, optional roles, approved substitutes, client approver, agency owner, and organizer calendar. Give each candidate a separate meeting ID, revision, contact consent, windows, proposals, approvals, provider event, and terminal state.
   • Candidate records can reference shared panel roles without referencing one another.
   • An ATS stage or interview-plan row is not a confirmed event.
   • Completion is evaluated independently for every candidate.
2. 2

   Partition candidate identity and availability

   Limit candidate identity, personal contact, current-employer sensitivity, availability windows, corrections, and decline reasons to authorized agency and client roles. The panel-capacity layer should see opaque candidate request IDs, duration, deadline, and eligible windows—not a list of candidate names attached to every open slot.
   • No candidate can discover another candidate through a link, poll, event title, or reply-all thread.
   • Routine logs redact candidate contact and message content.
   • The organizer and invite wording disclose only the approved search context.
3. 3

   Collect bounded candidate windows with consent

   For each candidate, state the client, stage, purpose, duration, format, date boundary, local-time zone, response use, reminder cap, and opt-out path. Accept windows, blackout periods, notice needs, corrections, decline, and expiry through the approved channel. Calendar connection is optional; do not ask candidates to expose a full personal or current-employer calendar.
   • Every response binds to one candidate, search, meeting revision, and channel message ID.
   • Ambiguous dates or zones receive one narrow clarification.
   • A correction invalidates only that candidate’s derived proposals.
4. 4

   Resolve one current panel-capacity map

   Read approved Google and Microsoft free/busy for required client roles. Request bounded windows from any unconnected interviewer. Normalize role, substitute eligibility, source, retrieval or reply time, IANA zone, consent, freshness, and provider error. Build panel intervals with exact required-role coverage before joining any candidate.
   • Missing access and provider errors are unknown, not open panel capacity.
   • Optional observers improve coverage without becoming blockers.
   • A named substitute cannot join until the client owner approves that role change.
5. 5

   Allocate proposals without leaking or overpromising capacity

   Intersect each candidate’s current windows with valid panel intervals. Apply the agency and client’s declared allocation policy, such as scheduling deadline, candidate response time, interview sequence, and protected panel load. Give every proposal an exact candidate record, panel evidence versions, expiry, hold state, and approval requirement. A proposal is not confirmation.
   • The allocation rule is recorded before it decides between candidates competing for one slot.
   • One panel interval cannot be promised to several candidates unless explicitly labeled and governed.
   • Candidates receive only their own proposal and expiry information.
6. 6

   Route client approval and candidate acceptance separately

   The client approves required interviewer assignment, substitute use, organizer, and any panel exception. The candidate accepts only their own exact slot and disclosed interview details. Bind both decisions to one proposal revision. If policy permits a tentative hold, name its owner, disclosure, expiry, and release rule.
   • The candidate is never asked to solve the client’s staffing decision.
   • The client does not receive unnecessary candidate calendar context.
   • Expired approval or acceptance cannot revive a stale proposal without fresh evidence.
7. 7

   Commit one canonical event per candidate

   Re-check current candidate evidence and required panel free/busy, then use an idempotency key tied to candidate meeting ID, revision, and approved proposal. Write one event, persist provider correlation and event IDs, send invitations, and read back time, zone, organizer, candidate, every required interviewer, optional decision, and invitation state. Reconcile a timeout before retry.
   • A repeated worker delivery cannot create a second candidate invitation.
   • Provider IDs from one candidate never attach to another candidate record.
   • Unused holds are released or closed under the declared policy.
8. 8

   Repair the shared panel without restarting every candidate

   When a required interviewer changes, invalidate the affected panel-capacity version and identify which candidate proposals or bookings depend on it. Preserve unaffected candidate windows, consent, approvals, and events. Reopen only the stale records, request only the missing update, and return a bounded substitute, date, duration, or priority decision to the client owner.
   • A panel change cannot trigger a broad candidate blast by default.
   • Each exception has one owner, deadline, and candidate-safe next action.
   • The final slate view separates waiting, proposed, approved, booked, declined, and reclaimed state.

Compare multi-candidate scheduling by how the slate stays isolated

The winning workflow shares panel capacity across the search while preserving one private, recoverable path from candidate windows to invitation for each person.