Anonymized Process Study · Recruitment Systems

Multi-Role Recruitment Scoring Engine

One reusable pipeline processes candidates for multiple positions while applying the correct eligibility rules, scoring weights, and thresholds for each role.

Privacy boundary: this page documents only the process architecture. It contains no client or organization identity, candidate identity, private link, position name, or claim about who commissioned or implemented the system.

Core pipeline Tally Intake→ Airtable→ n8n Scoring→ Airtable Results→ Google Drive

1 engineshared scoring workflow instead of one workflow per position

Many roleseach position resolves its own rubric through position_id

1 batchall eligible candidate records can enter the same processing run

Core Problem

Different positions need different scoring rules

A fixed prompt or one universal score can compare candidates against the wrong requirements. The engine therefore separates candidate data from role criteria and selects the correct rubric before scoring begins.

Candidate

One normalized profile

Application answers and document references are converted into a consistent candidate payload regardless of the selected position.

Position

One role identifier

Each record carries a stable position_id used to resolve the matching qualifications, weights, thresholds, and required documents.

Engine

One reusable workflow

The same n8n workflow evaluates every eligible record with its resolved role rubric, avoiding duplicated automation for each vacancy.

Architecture

Separate candidate records from Role Criteria

Airtable remains the single source of truth for both candidate records and position-specific rules. n8n joins them at runtime; Google Drive remains the document-storage layer.

1 · TallyCollect candidate data, selected position, and document references.

2 · CandidatesStore one record per applicant with position_id, record_id, and Status.

3 · Role CriteriaStore the eligibility rules, dimension weights, and thresholds for each position_id.

4 · n8n EngineFetch all eligible candidates, resolve each rubric, score, and prepare results.

5 · Airtable + DriveWrite results to the originating record and retain referenced documents in Drive.

Key design rule: adding or changing a position updates the Role Criteria data. It does not require cloning the workflow.

Single Run · Multiple Rubrics

Process all eligible candidates through one engine

“All at once” means one batch run can contain candidates from different positions. Each item is evaluated independently with the rubric linked to its own position.

Stage	Engine behavior	Control
1 · Fetch	Read every candidate where `Status = BARU`, regardless of position.	Exclude previously processed records.
2 · Resolve	Use `position_id` to load the matching Role Criteria record.	Stop the item if no active rubric is found.
3 · Gate	Check mandatory qualifications and required application evidence.	Keep hard requirements separate from weighted scoring.
4 · Score	Evaluate Skill, Experience, Education, and University dimensions with role-specific rules.	Return structured fields, not free-form output.
5 · Calculate	Calculate Final Score from the resolved role weights and store the recommendation.	Keep the calculation visible and reviewable in Airtable.
6 · Update	Write results to the originating candidate using Airtable `record_id`.	Preview field mapping and fail closed when identity is missing.

for each candidate where Status = BARU:
  rubric = RoleCriteria[candidate.position_id]
  assert rubric is active

  result = score(candidate, rubric)
  update candidate.record_id with result

Data Integrity

Keep role selection and record identity attached end to end

The engine is only reliable when the candidate’s position_id and Airtable record_id survive every transformation.

Failure mode

Context replaced by score output

If a code node returns only the scoring result, downstream nodes lose the candidate identity and can no longer select the correct record or rubric.

Required contract

Carry identity explicitly

Every item retains record_id, position_id, the normalized candidate payload, the resolved rubric version, and the structured scoring result.

return {
  record_id: candidate.record_id,
  position_id: candidate.position_id,
  rubric_version: rubric.version,
  candidate,
  scoring_result
};

Locked controls: process Status = BARU only; reject missing or inactive rubrics; update by Airtable record ID; preview mappings before write; retain the rubric version used for each score.

Process Result

One scalable model for multiple vacancies

The architecture avoids separate workflows and hard-coded prompts for every position. Recruitment rules remain configurable as data, while one engine processes the full candidate batch with traceable role and record identity.

One candidate schema supports applications across multiple positions.
Each position owns an independent and versioned scoring rubric.
One batch may contain candidates for different positions.
Every result remains linked to the correct position and candidate record.
No client, organization, candidate, or project identity is disclosed.

Need one engine for multiple recruitment tracks?

A role-driven scoring model keeps criteria configurable without duplicating the automation for every vacancy.

Discuss a system Back to portfolio