Screen a Candidate List at Volume — Outbound Calling

By the end of this guide you will be able to take a list of people who have agreed to be contacted, call and text them, screen them against your own criteria, and route only the ones who pass — or who say something that needs a person — to your team. The rest complete without anyone on the line.

Plan a day to build it and a second day to run a test batch. Run a test batch before you point it at a real list. Outbound calling is not undoable.

Before you start

• Your workspace needs phone and calendar enabled, and at least one phone number you own. If Phone is not in the sidebar, ask your Gravity Rail contact.
• Have your screening questions written down in the order you want them asked, with the answer that disqualifies each one.
• Have your list as a CSV with, at minimum, a reference, a phone number and a preferred language.
• Know your rules for contact hours and opt-outs before you start, not after.

1. Define what a screening result is

Create a DataType — the platform's name for a structured record — called Screening Result, with one field per question plus an outcome field.

Make the answer fields choice fields, not free text. This is the difference between being able to say "412 screened, 96 passed, 71 failed on visit distance" and having to read 412 transcripts to find out.

You'll know it worked when you can add a record by hand and every question has a fixed set of answers to pick from.

2. Load the candidate list

Import your CSV as Members. Map the reference column to an external ID field so you can match a candidate back to your own system later. Map preferred language — it decides which script they get.

You'll know it worked when the imported count matches your CSV row count, and spot-checking three records shows the phone number in the right field.

3. Write the screening script as an Agent

Create an Agent and give it the questions in order. Tell it explicitly:

• to stop as soon as a disqualifying answer comes back, and record which question it stopped at;
• to record every answer into the Screening Result record as it goes, not at the end — a call that drops halfway should still leave you the answers you got;
• to hand off immediately, at any point, if the person asks for medical advice, describes a symptom getting worse, or asks to stop being contacted.

Write the handoff conditions as explicit instructions. An agent that has not been told what to escalate will try to handle it.

You'll know it worked when you can hold a test conversation with the agent by text and it stops at the first disqualifying answer instead of finishing the list.

4. Build the outreach Workflow

A Workflow is the sequence that runs per candidate. Yours:

1. Call the candidate.
2. If they don't answer, send a text with a callback option.
3. On answer, run the screening Agent.
4. On pass — or on any handoff condition — route to a human.
5. Write the outcome to the Screening Result record.

Set your contact-hours window on the workflow so calls respect the candidate's local time. Do this now, not later; it is the control a monitor asks about.

You'll know it worked when the workflow saves with all five steps and shows a contact-hours window.

5. Put your coordinators on the receiving end

Add your coordinators as members with a role that can take conversations but cannot reconfigure the workflow — see Live Operator Mode. When a candidate is routed to a person, the coordinator picks up with the whole conversation already in front of them, so nobody gets asked the same question twice.

You'll know it worked when a coordinator logged in as themselves sees a handed-off conversation and can reply to it — and cannot see the workflow editor.

6. Run a test batch of ten

Use ten records that are yours, or colleagues who have agreed. Watch it live.

Check all five: calls placed in the window, texts sent on no-answer, answers landing as fields on the record, a passing candidate reaching a coordinator with context, and an opt-out actually stopping contact.

You'll know it worked when you can produce the count — contacted, reached, screened, passed — without opening a single transcript.

7. Answer the monitor's question before they ask it

Candidate records live in your workspace, visible to members you have added, scoped by their role. Contact attempts and record changes are captured in the audit log, which you can read yourself.

Before you go to a sponsor, do this once: change a record, then find that change in the audit log with your own login. Knowing where to look is the difference between answering the question and promising to follow up.

You'll know it worked when you have found your own edit in the audit log.

When it doesn't work

What you see	What it means	What to do
Calls go out at the wrong local time	Contact hours are set on the workspace, not on the workflow, or the candidate's timezone is unset	Set the window on the workflow; check the imported timezone
Every candidate completes the full question list	The agent was not told to stop on a disqualifying answer	Re-state the stop condition explicitly per question
Answers arrive as one transcript blob	The workflow writes at the end instead of per answer	Move the record write inside the screening step
Coordinators see the workflow editor	They were added as Managers	Give them a role with conversation scopes but not workflows:write
Nobody picks up a handoff	No operator is available, or none is assigned to the group	Check operator availability before blaming routing
An opt-out still gets called	Opt-out was recorded on the record but not as a contact preference	Record it where contact rules read it, then re-test

What to do next

Once a batch runs clean, the next thing to add is the reminder for candidates who passed and have a visit booked — the same workflow shape, triggered by the visit date rather than by the list. Do that only after your first real batch, not before.