Setting Up Your First AI Screening Campaign in HireQwik

A TA manager at a fintech with 500+ campus hires a year once told us she’d rather write the job description twice than touch “campaign setup” in a new tool once. She’d been burned before: three tabs of config, a mapping step nobody explained, and a launch that silently failed because one field was named wrong. We built the HireQwik setup flow to be the opposite of that story, and this guide walks through exactly how to set up an AI screening campaign in HireQwik, start to finish, the way we’d walk a new HR user through it on a call.

If you’ve read about HireQwik’s trigger-based screening or the per-JD rubric as separate ideas, this is where they come together as one setup you actually run. There are four real steps: upload the JD, connect the sheet, let the trigger flow enrich and invite candidates, and watch the queue fill in your dashboard. None of them require an engineer, and none of them require HR to manually email a single candidate.

Step 1: Upload the job description and let HireQwik build the rubric

Campaign setup starts with the JD, not a settings page. You paste or upload the job description into HireQwik, and the system runs it through a structured screener-build step that turns the JD into a scoring rubric specific to that role — not a generic template applied to every opening. This is the mechanic behind the per-JD screening rubric: a CSM_BFSI role and a backend engineering role get different questions and a different scoring emphasis, because the JD said so.

While it’s building the rubric, HireQwik also drafts phase-0 knockout questions from anything in the JD that reads as a hard disqualifier — a specific certification, a location requirement, a minimum notice period. These are the questions that run first on every call and can end an interview inside the first two minutes if a candidate fails one, tagged “knockout” in the review queue so HR can see exactly why. We cover the mechanics of that part separately in our knockout questions walkthrough — for setup purposes, the only thing you need to do here is review the drafted rubric and knockouts before moving on, not build them from scratch.

Step 2: Connect your Google Sheet (paste the URL, not just the ID)

This is the step that used to trip people up. Until July 2026, the “Connect Sheet” field on the JD trigger-config screen only accepted a bare Google Sheet ID — the long string of characters after /d/ in a Sheets URL. Paste the full browser URL instead, which is what everyone actually has copied, and the connection would save without error and then silently fail the first time the sheet poller ran looking for new rows.

That’s fixed now. The Connect Sheet field accepts a pasted full URL (https://docs.google.com/spreadsheets/d/…) directly and resolves it to the correct ID automatically. If you paste something that isn’t a valid Sheets URL — a non-Sheets Google link, empty input, unrecognizable text — you get a specific inline error before saving, instead of a campaign that looks connected but never triggers. It’s the single most common place a first-time setup used to stall, which is exactly why we built the per-JD trigger flow around a sheet connection that fails loudly instead of quietly.

Your sheet needs one row per candidate with, at minimum, a name, email, and a resume link or attachment column HireQwik can read. Everything past that — a phone number, source, referral tag — is optional and gets carried through untouched.

Step 3: Let the trigger flow take over

Once the sheet is connected, you don’t do anything else per candidate. New rows get picked up automatically: HireQwik enriches the row, scores the resume against the JD-specific rubric from Step 1, and — if the candidate clears whatever bar you’ve set — emails a self-schedule link. No HR person touches this step. That’s the entire point of a per-JD trigger flow: a recruiter connects the sheet once, and every subsequent row that lands in it becomes a scored, invited candidate without anyone re-opening the tool.

The self-schedule link isn’t just a booking page. When a candidate picks a slot, the confirmation email carries a real calendar attachment — an RFC 5545 .ics file, the same iCalendar standard Outlook and Gmail both read natively, with a working RSVP and a 15-minute reminder baked in. If a candidate reschedules and gets a new link, the .ics carries a stable UID tied to the original booking, so the calendar entry updates in place instead of leaving a duplicate ghost event on their calendar. It’s a small detail, but it’s the difference between a booking flow that feels like a real interview and one that feels like a form submission.

That detail matters more than it looks like it should. One 2026 analysis of recruiting-coordination workloads found that coordinators using automated interview scheduling handle roughly five times as many interviews per week as those coordinating manually — the time saved isn’t just in sending invites, it’s in every candidate never having to email back and forth to fix a broken calendar entry.

Candidates aren’t left to figure out scheduling alone, either — and they aren’t infinitely flexible about it. HireQwik caps reschedules at three attempts within 72 hours of the first booking; past that, the slot picker locks and HR gets a note to reset it manually. We go into why that cap exists, not just that it exists, in our reschedule-limit deep dive — worth reading if you’re setting up a campaign for a role where you expect a lot of last-minute reschedule requests.

Step 4: Watch the queue, not your inbox

Here’s what changes once the campaign is live: HR stops checking email for interview confirmations and starts checking one screen. Every completed interview lands in HireQwik’s HR dashboard at https://app.hireqwik.in/dashboard/hr, sorted into a verdict — Strong Go, Go, On Hold, No Go — the moment the AI evaluator finishes scoring it. You don’t set up a separate step for this; it’s just where the campaign’s output shows up once candidates start booking and completing interviews.

If you opted a JD into auto-decide thresholds during setup, some of that sorting happens without a human touching it at all: candidates scoring below your reject threshold or above your fast-track threshold get moved automatically, and only the middle “Needs review” band lands in front of HR. That’s a setup choice, not a default — you can leave every candidate in the manual-review queue if that’s what your team wants for a given role. Either way, this is the step where a campaign stops being a config screen and starts being a stream of decisions you actually act on.

What setup automates vs. what you actually configure

New users often assume “AI screening setup” means configuring a dozen toggles. In practice, most of the work happens automatically once you give HireQwik a JD and a sheet — you’re reviewing and approving more than you’re building.

The pattern is consistent: HireQwik automates anything that happens per-candidate, and leaves per-role decisions — the rubric, the thresholds, whether to turn on auto-decide at all — in HR’s hands. That split is deliberate. A recruiter should be able to look at any completed setup and know exactly which choices were theirs.

Running more than one campaign at a time

Nothing about this setup assumes you’re only ever running one JD. Each job description gets its own trigger config, its own connected sheet, and its own rubric, so a TA team running a campus drive for a support role and a lateral search for a senior engineer at the same time isn’t sharing a queue or a rubric between them — they’re two campaigns that happen to route into the same HR dashboard. That matters more than it sounds like it should: a rubric tuned for filtering 2,000 fresher applicants down to a shortlist behaves very differently from one tuned to distinguish between 15 senior candidates who all look qualified on paper. Setting each JD up separately, even when it feels redundant for a small role, keeps that difference intact instead of averaging it away.

What a first campaign actually looks like end to end

Put together, setup for one role looks like this in practice:

1. Paste the JD into HireQwik and review the auto-generated rubric and knockout questions (5 minutes)
2. Paste your Google Sheet’s full URL into Connect Sheet, not just the ID (30 seconds)
3. Confirm your sheet has name, email, and resume columns, then save
4. Drop the campaign live and add candidate rows to the sheet as they come in
5. Check the HR dashboard once interviews start completing, instead of your inbox

Most first-time setups fit into one sitting once the JD is written, and none of it involves a call with us — though we’re happy to look at your rubric if a JD is unusual enough that you want a second pair of eyes on it before going live.

The setup mistake that costs the most time

The single most common setup mistake isn’t technical — it’s skipping the rubric review in Step 1. HireQwik drafts a strong rubric from most JDs, but a JD written loosely (vague seniority language, a certification listed as “preferred” that’s actually a hard requirement) produces a rubric that inherits that looseness. The fix costs two minutes at setup and saves hours of reviewing candidates who never should have cleared the resume score in the first place. If you’re setting up campaigns for very different hiring contexts — say, a high-volume campus drive next to a lateral senior-engineer search — the rubric and knockout differences between those two setups are big enough that we wrote a separate comparison: AI screening setup for campus hiring vs. lateral hiring.

The second most common mistake is closer to a false alarm than a real problem: assuming the campaign is broken because the queue is empty on day one. If that happens to you, work through it as a diagnostic problem rather than a setup problem — our guide to a sheet that isn’t triggering interviews covers the six most common causes in the order we’d actually check them.

Setting a campaign up correctly the first time is what makes everything after it — the dashboard review, the auto-decide bands, the self-schedule flow — work the way it’s supposed to. Get the JD and the sheet connection right, and the rest runs itself.