REDCap Survey Queue and Automated Invitations

REDCap’s Survey Queue and Automated Survey Invitations (ASIs) solve two different problems that get run together constantly, because both involve “getting a participant to fill out the next survey.” Automated Invitations decide when and whether an invitation email goes out — the participant isn’t in a survey session yet. The Survey Queue decides what happens once a participant is already inside a survey session and has just finished one instrument. Confusing the two produces two common failure modes: a queue configured correctly with no invitation ever triggering it, or an invitation configured correctly with the participant landing on a dead-end completion page instead of moving to the next instrument. This guide covers both mechanisms, how their condition logic works, and how to combine them into one coherent multi-instrument participant experience.

REDCap (Research Electronic Data Capture) is developed and distributed through the non-profit REDCap Consortium rather than sold as a commercial product with public pricing — a project exists inside a REDCap instance hosted by a consortium partner institution, not a REDCap-owned cloud service. Both features covered here are standard functionality inside REDCap’s project-building interface (Online Designer), not a paid add-on. See CASRAI’s REDCap dictionary entry for the platform overview, and Is REDCap HIPAA-Compliant? for what the platform’s compliance framing does and doesn’t guarantee automatically for the survey data these two features move around.

Automated Survey Invitations: getting someone into the survey

An Automated Survey Invitation (ASI) is a scheduled, conditional email REDCap sends on the study team’s behalf, without a coordinator manually composing and sending one per record. Each survey instrument in a project can carry its own ASI configuration, set from that survey’s settings in Online Designer. An ASI needs three things to actually fire:

• An email address to send to. REDCap has to know which field in the project holds the recipient’s email — set via the Participant List (or a field designated as that survey’s email-invitation field), not entered ad hoc per invitation. No mapped email field, no invitation, and typically no visible error either.
• A trigger. ASIs are scheduled relative to something: immediately, a fixed calendar date, or relative to a date/datetime value already stored on that record — an enrollment-date field, or the completion timestamp of an earlier instrument. Scheduling off a stored date field is what lets an invitation go out a fixed interval after a real study event, rather than whenever someone happens to check the project.
• Conditional logic (optional). An ASI can carry the same branching-logic syntax used elsewhere in REDCap — see CASRAI’s guide to REDCap branching logic — so the invitation fires only for records matching a condition: a particular study arm, or only records where an earlier instrument was actually completed.

REDCap can also be configured to automatically re-send a reminder to a record that hasn’t completed the survey yet, at a set interval after the first invitation — useful for chasing non-responders without a coordinator manually tracking who’s outstanding. Reminders inherit the same conditional-logic gate as the original invitation, so a record that stops meeting the condition (a participant who withdrew, for example) stops receiving reminders once the underlying data reflects that.

The Survey Queue: moving between instruments once someone is already in

The Survey Queue is a project-level setting, also configured in Online Designer, that links multiple survey instruments into an ordered sequence for the same record. Once a participant finishes one survey in the queue, REDCap either displays a link to the next survey on the completion page or moves them straight into it, depending on that survey’s Auto-Continue setting.

• Queue order follows the order instruments are arranged in the project by default, but any survey in the queue can carry its own Queue Logic — a condition, using the same branching-logic syntax as everywhere else in REDCap, that determines whether that specific survey is offered to that specific participant at all. This is what lets one project route different participants through different subsets of instruments based on answers already given — a screening survey that only routes eligible participants into the full baseline battery, for example — instead of every participant seeing every survey in a fixed order.
• Auto-Continue is set per survey and controls what the participant experiences the moment they finish it: with Auto-Continue on, REDCap takes them directly into the next queued survey with no extra click; with it off, they land on a standard survey-completion page carrying a link into the next instrument that they have to click themselves. Auto-Continue is the setting most likely to produce a “why did the participant stop after survey one” report — it defaults off, so a queue that’s technically configured correctly can still look broken if nobody clicks through.

Two constraints worth knowing before designing around the Queue: it only sequences surveys within the same project for the same record — it does not span separate REDCap projects — and every survey a participant should be able to reach through the queue has to actually be enabled as a survey (not left as an internal data-entry-only instrument) in that project.

Combining the two: an invitation-to-completion flow across multiple instruments

A typical multi-instrument design uses both mechanisms for different parts of the same flow: an ASI, carrying its own conditional logic and usually a stored-date trigger, sends the first invitation and starts the participant’s involvement; once they’re inside that first survey, the Survey Queue, carrying its own Queue Logic on each subsequent survey, takes over the routing between instruments without needing a fresh emailed invitation at every step. This division matters for design, not just terminology: the ASI’s logic controls who gets invited at all, and when; the Queue’s logic controls which instruments an already-participating record sees, and in what order. A record can fail the ASI’s condition and never get invited at all, or pass it, get invited, and then be routed past some later instruments by Queue Logic based on how it actually answered earlier ones — these are two independent gates, and both need to be tested, not just one.

Worth checking specifically during setup: whether an instrument reachable only through the Queue also needs its own ASI as a fallback, for a participant who starts the sequence, closes the browser partway through, and needs to be re-invited into a later instrument rather than starting over — REDCap does not automatically re-invite a participant who abandons mid-queue. An eConsent instrument built with REDCap’s own eConsent framework (see CASRAI’s REDCap eConsent Framework guide) is frequently the first survey in a sequence like this, gating everything downstream in the queue on consent actually being captured.

Common pitfalls

• No email field mapped for the survey. The most common reason an ASI silently never sends anything — there’s often no obvious error message, the invitation simply has no recipient to go to.
• Auto-Continue left off when the design assumed it was on. Participants stall on a completion page that looks like a dead end even though the next survey is correctly queued behind it.
• Queue Logic or an ASI condition referencing a field that’s itself a calculated field. If that field hasn’t recalculated by the time the condition is evaluated, the logic can read a stale value — see CASRAI’s guide to REDCap calculated fields for the same recalculation-timing trap in a different context.
• Testing in the live project instead of a test/draft copy. ASIs sent from a live production project go to real recipients; building and testing a queue-and-invitation design in a separate test project (or REDCap’s project-copy tools) avoids emailing real participants while working out the logic.

A few related mechanics worth knowing about if a queue design gets more elaborate: personalizing an invitation email or a later queued survey’s question text with an earlier response uses REDCap’s piping syntax (see CASRAI’s guide to piping in REDCap); a queue that routes different survey batteries by treatment arm often reads that arm assignment straight from REDCap’s own randomization module (see CASRAI’s guide to the REDCap randomization module); and editing Queue Logic or ASI conditions changes the project’s field structure the same way any other field edit does, which is where CASRAI’s guide to the REDCap data dictionary is relevant. Once a full queue is complete for a batch of participants, pulling the collected responses out programmatically is covered in CASRAI’s guide to the REDCap API. And if REDCap versus another survey platform is still an open question rather than a settled one, see CASRAI’s comparison of Qualtrics vs. REDCap.

Frequently asked questions

Do I need Automated Invitations if I’m already using the Survey Queue?

Only for the first survey in the sequence, or to re-invite a participant who drops out mid-queue. Once a participant is inside the queue, the Queue itself — not a fresh ASI — moves them from one instrument to the next.

Can Queue Logic and Automated Invitation logic reference the same field?

Yes — both use REDCap’s standard branching-logic syntax, so a field captured on an earlier instrument can gate both whether a later invitation goes out and whether a later survey appears in the queue. They’re evaluated independently, though, so verify both conditions produce the outcome intended rather than assuming one implies the other.

Does the Survey Queue work across separate REDCap projects?

No — the Queue sequences surveys within one project for one record. Moving a participant into a genuinely separate project requires its own invitation into that project, not a queue link.

What happens if a participant is eligible for the queue but the email field used for the original ASI was never filled in?

The original invitation never sends, so the participant never enters the survey session the Queue depends on. The Queue only ever governs what happens after someone is already inside a survey — it has no way to independently invite someone in the first place.