Manual editor recipe

AI job-fit scoring with Zapier

Build a scheduled Zap that runs one bounded candidate search, filters validated fit rows, and updates or creates a Google Sheets row by candidate-specific matchKey.

Not an importable ZapBuild latestFive-result starter
Open the editor recipe ↗Review the scorer

Availability boundary

Zapier does not provide a portable workflow-import file for this maintained recipe. The repository contains a human-readable editor specification. It is not a published Zap, does not include credentials, has not proved an authenticated editor build, and is not evidence that a named Google Sheet received a row.

Build the Zap

  1. Add Schedule by Zapier → Every Day, keeping the Zap off during setup.
  2. Add Apify → Run Actor for job-atlas/ai-job-fit-scorer. Select latest, wait for completion, use the bounded five-result shortlist input, and cap result charges at $0.10.
  3. Add a required Webhooks GET for the returned run ID. Require SUCCEEDED, exit code 0, and unchanged actor/run/build identity.
  4. Add a required Webhooks GET for RUN-SUMMARY from that run’s default key-value store. Map its JSON body to the summary input of the filter.
  5. Fetch only that run’s default dataset. Before any Sheet write, require summary actor/run/build fields to match the exact run receipt, plus scored fit rows meeting delivery score 2.
  6. Look up a Google Sheets row by matchKey; update one exact match or create a new row.

Map the candidate-specific destination

Import the repository’s 21-column fit header into a disposable Sheet. Preserve matchKey, evaluationKey, candidate hashes, fit and delivery scores, recommendation, evidence summaries, source run/build, and a bounded serialized copy of the evaluation.

Do not use jobKey as the lookup key. It identifies one source posting and would allow candidate A’s evaluation to overwrite candidate B’s.

Validate before activation

  1. Inspect current nomad-ai-job-fit-run-summary-v4 from the exact run’s key-value store.
  2. Reconcile dropped, held, scored, failed, filtered, and output counts; confirm shortlist rows meet the delivery threshold and one $0.02 event exists per returned row.
  3. Prove one named row is created in a disposable Sheet.
  4. Repeat the same fixture and prove the same row is updated rather than duplicated.
  5. Use filtered, audit, and ai_failed fixtures to prove unsafe rows are blocked.
  6. Only then activate the schedule and record the run, build, destination, and verification time.

Troubleshooting

  • Build or storage fields are missing: use authenticated Webhooks steps to re-read the returned run; never substitute a latest-run lookup.
  • Duplicate candidates: inspect the lookup column and confirm it is matchKey.
  • Wrong charge: stop the Zap, confirm the immutable build reported by the exact run, row status, result meter, and maximum total charge.
  • No Sheet row: distinguish a safe filtered outcome from a connection, field-mapping, or permission failure.