Why Your Google Sheet Isn't Triggering AI Screening

Three days into a campus drive, a recruiter checked her HireQwik dashboard expecting a queue full of completed interviews. It was empty. Her sheet had 200 rows in it. Zero candidates had been invited, let alone screened. This is the single most disorienting failure mode in AI screening setup — everything looks configured correctly, the sheet is visibly full of data, and nothing is happening — and it’s almost never one obvious cause. It’s usually one of six, and this post walks through them in the order we’d actually check.

Before troubleshooting, confirm you’ve completed the basic connection steps in Step 2 of our campaign setup guide — this post picks up after a connection that appears successful but isn’t actually moving candidates through.

1. Check sharing permissions first — it’s the most common cause

If the sheet isn’t shared with HireQwik’s access, the connection can still save without an error, because saving the connection only validates that the URL or ID resolves to a real sheet — it doesn’t confirm HireQwik can actually read its contents. Open your sheet’s sharing settings and confirm it’s shared appropriately for your org’s Google Workspace policy (either with HireQwik’s service account directly, or set to “anyone with the link can view,” depending on how your admin has it configured). This single setting accounts for more silent-failure reports than every other cause on this list combined.

2. Confirm your header row matches what HireQwik expects

HireQwik maps columns by header text, not position. If your headers were renamed, translated, or if someone inserted a second title row above them, the mapping can lose track of which column holds the email address or the resume link. Look specifically for:

• A merged “Candidate Info” title row sitting above your actual headers
• Headers that were bulk-renamed by an ATS export (e.g., “E-mail” instead of “Email”)
• A header row that isn’t the first row in the sheet

If in doubt, the fastest fix is deleting and retyping the header row in plain text, no formatting, no merged cells.

3. Look for a resume column HireQwik can’t actually read

A resume “link” that’s really an uploaded file icon, a Drive link set to restricted access, or a formula that displays a value but doesn’t resolve the same way through the Sheets API will all look fine to a human scanning the sheet and fail silently for HireQwik. Click into a few resume cells directly rather than trusting what’s visually rendered. If you’re pulling resume links from an ATS export, check one manually in an incognito browser tab — if it prompts you to request access, HireQwik hit the same wall.

4. Check whether your knockout questions are failing everyone

This one doesn’t look like a connection problem, but it produces the same symptom: zero completed interviews. If a phase-0 knockout question is misconfigured — checking for a requirement that’s actually disqualifying every candidate in your pool, or phrased ambiguously enough that the AI evaluator is reading it too strictly — candidates get invited, take the call, and immediately get rejected in the first two minutes. The queue looks empty of anything worth reviewing, but the interviews are happening; they’re just all ending in a knockout reject. Check your dashboard’s rejected/knockout tab, not just the pending queue, before concluding nothing is triggering at all. If this is the actual cause, revisit how knockout questions get drafted from the JD — they’re generated automatically and need a human check before go-live for exactly this reason. This is more likely to bite a lateral search than a campus drive, since a lateral JD’s knockouts tend to check specific experience requirements that are easier to phrase too strictly — see our campus vs. lateral setup comparison for how the two differ.

5. Check your resume-score threshold isn’t set too high

If you configured a minimum resume-match score before a candidate gets invited to interview, and set that threshold aggressively, you can end up in a state where every incoming row scores just under the bar. This is more likely on a JD with unusually specific requirements or a rubric that wasn’t reviewed carefully after being auto-drafted. Pull up a sample of recent rows and check their resume scores directly — if they’re clustering just below your threshold, the fix is either loosening the threshold or revisiting whether the rubric is scoring too strictly for the actual candidate pool you’re getting.

6. Confirm the poll cycle has actually run

HireQwik polls connected sheets for new rows on an ongoing basis rather than instantly on every keystroke, in part because Google’s own Sheets API enforces per-minute read quotas that any integration polling a live sheet has to respect rather than checking continuously. If you added 200 rows in the last two or three minutes, give it a short window before assuming something is broken — this is rarely the actual cause of a multi-day silence, but it’s worth ruling out before you start changing settings, since a genuine config fix made mid-poll-cycle can be hard to distinguish from “it just hadn’t run yet.”

The diagnostic order, as a checklist

1. Sharing permissions — can HireQwik actually read the sheet?
2. Header row integrity — are name/email/resume columns mapping correctly?
3. Resume column format — do the links actually resolve, or just look like they do?
4. Knockout tab, not just pending queue — are interviews happening and instantly rejecting?
5. Resume-score threshold — is the bar quietly filtering out your whole pool?
6. Poll timing — has enough time passed since the rows were added?

Work through them in this order. Sharing permissions and header mapping account for the overwhelming majority of “nothing is happening” reports we see, which is why they’re first — checking auto-decide thresholds before confirming HireQwik can even read the sheet is solving the wrong problem first.

What that three-day silence actually turned out to be

For the recruiter in the opening, it was cause #1. Her org’s IT policy had recently changed default sharing on new Google Sheets from “anyone with the link” to “restricted to organization members only,” which meant every sheet created after that policy change quietly stopped being readable by HireQwik’s service account — including the connection she’d made three days earlier, which had saved without any error at all. Nothing about her setup screen ever indicated a problem. The fix took ninety seconds once she knew to look at sharing settings specifically. The three days lost weren’t a HireQwik problem or a candidate problem; they were a silent policy change nobody had connected to a screening campaign until the queue stayed empty long enough to notice.

That’s the pattern worth internalizing: the failure mode that costs the most time is never the one with an error message attached. It’s the one where everything reports success and the actual breakage is one layer removed from anything the setup screen checks.

Preventing this on your next campaign

A few habits catch most of these causes before they cost you days instead of minutes:

• Add a test row immediately after connecting, using your own email, and confirm it enriches and invites within one poll cycle before adding real candidates.
• Re-check sharing permissions after any org-wide Google Workspace policy change, even on sheets that were working fine before — a policy update can silently break an existing connection, not just a new one.
• Check the knockout and rejected tabs on day one of a new campaign, not just the pending queue, so a misconfigured knockout question gets caught within hours instead of days.
• Note your resume-score threshold somewhere visible when you set it, so a quiet zero-invite pattern gets compared against a known number instead of triggering a fresh investigation from scratch.

None of these take more than a couple of minutes, and together they turn “three days of silence before anyone noticed” into “caught on the first test row.”

What a working connection looks like, for comparison

It helps to know what success looks like so you can tell a real failure from an over-cautious assumption that something’s wrong. A working connection, after adding a valid row, should show that row enriched and scored in the dashboard within one poll cycle, and if the candidate clears your threshold, a self-schedule email lands in their inbox in the same window. If you’ve waited well beyond a normal poll cycle and see nothing change, that’s the point to start working through the checklist above rather than waiting further.

One related symptom worth separating from a triggering problem entirely: if candidates are getting invited but several are stuck unable to book a slot, that’s not this checklist — it’s more likely the reschedule limit locking out candidates who’ve burned through their attempts, which looks similar to a stalled queue but has a completely different fix.

A campaign that looks broken usually isn’t broken in the way it first appears. Work the checklist top to bottom, and the fix is almost always one setting, not a rebuild. If you’ve worked through all six and the queue is still empty, send us the details — that combination is rare enough that it’s usually worth a second pair of eyes.