Deep-Dive Guide for Scheduled and Logic-Based Survey Invitations

REDCap Automated Survey Invitations (ASI)

Automated Survey Invitations (ASIs) allow REDCap to send survey invitations automatically when specified conditions are met. They are especially useful for follow-up surveys, scheduled outreach, longitudinal workflows, and any study that needs repeatable, rule-based survey distribution.

Core Principle: ASIs do not simply “send surveys later.” They work by evaluating logic, scheduling invitations, and then sending them according to the timing rules you define.
Important: ASIs require careful planning and testing. Poorly designed logic, missing email fields, or incorrect timing assumptions are among the most common causes of survey invitation errors.
Quick Setup Checklist:

  • Confirm the survey is enabled
  • Confirm a valid email field is designated
  • Open the correct survey’s ASI setup in Online Designer
  • Write and test the trigger logic
  • Choose the correct send timing
  • Configure reminders only if needed
  • Leave the ASI inactive until testing is complete
  • Activate only after full end-to-end validation

What ASIs Are

Automated Survey Invitations are invitations that REDCap schedules and sends automatically when a defined condition becomes true. Unlike manual invitations sent through the Participant List, ASIs do not require a person to send each message individually. :contentReference[oaicite:2]{index=2}

ASIs are commonly used for:

  • Follow-up surveys sent after a baseline survey
  • Surveys sent after a delay, such as 7 days after enrollment
  • Time-based or event-based invitations
  • Conditional invitations based on study data

Requirements Before You Begin

Before setting up an ASI, make sure the following are already in place:

  • The instrument is enabled as a survey
  • A valid email field has been designated at the project or survey level
  • The survey workflow and trigger conditions are fully planned
  • If the project is longitudinal, you know which event the invitation belongs to
Important: ASIs do not work on projects enabled with repeating instruments/events. :contentReference[oaicite:3]{index=3}
Important: If no valid designated email field exists, the ASI cannot be delivered even if the logic is correct. :contentReference[oaicite:4]{index=4}

How ASIs Work

Every ASI consists of three core parts:

  1. Compose the invitation – subject line and message
  2. Define the trigger condition – what must happen for REDCap to schedule the invitation
  3. Define when to send – immediately, after a delay, or relative to a date/date-time field

Once the trigger condition becomes true, REDCap schedules the invitation. A separate process then sends it at the appropriate time. :contentReference[oaicite:5]{index=5}

Key Distinction: The trigger condition determines when the invitation gets scheduled. The timing setting determines when the scheduled invitation is actually sent.

ASI Setup Steps

To configure an ASI:

  1. Go to Online Designer
  2. Click Automated Invitations for the appropriate survey
  3. If the project is longitudinal, select the correct event
  4. Complete the four ASI sections:
    • Step 1: Compose message
    • Step 2: Define conditions
    • Step 3: When to send
    • Step 4: Activated?

Step 1: Compose Message

  • Select the sender address
  • Enter the subject line
  • Enter the message body
  • Keep the survey-link smart variable intact
Important: The survey link in the invitation is a smart variable and must remain in the correct format. Once the invitation is scheduled, REDCap resolves that text into the participant’s unique private survey link. :contentReference[oaicite:6]{index=6}

Step 2: Define Conditions

Specify the condition that tells REDCap when the invitation should be scheduled.

Examples include:

  • When a prior survey is completed
  • When a field is populated
  • When a calculated logic expression evaluates as true

Step 3: When to Send

Specify whether the invitation should be sent immediately, on the next chosen day/time, after a specific delay, or relative to a date/date-time field.

Step 4: Activated?

Save the ASI while it is inactive during setup and testing. Activate it only after the logic and timing are fully validated.

Best Practice: Keep ASIs inactive during development and use realistic test records before activation.

Writing ASI Logic

ASI logic can be simple or complex, but it should always be intentional, readable, and testable.

General guidance

  • All fields in all forms and arms are available to ASI logic
  • If a field has no value, REDCap treats it as an empty string
  • For longitudinal projects, include the event reference when needed
  • Use a dedicated “kill switch” field to stop invitations when needed

Example kill switch logic:

datediff([surgery_arm_2][surgery_date], 'today', 'd', true) >= 6 and [enrollment_arm_1][prevent_surveys] != '1'

Using datediff

The datediff() function is often used in ASIs to trigger invitations based on elapsed time between dates. It is especially useful when invitations depend on a visit date, surgery date, or other participant-specific date field. :contentReference[oaicite:8]{index=8}

Design Tip: It is often easier to validate complex ASI logic first in a custom report or Data Quality rule, then copy that working Boolean logic into the ASI.
Important: The today variable should generally be used with datediff. Comparing today directly to a date field is unreliable. :contentReference[oaicite:9]{index=9}

Scheduling and Timing Options

ASIs can be sent in several ways after the trigger condition becomes true:

  • Immediately
  • On next day/time
  • After X days/hours/minutes
  • Relative to a date or date-time field

Common use cases

  • Send 7 days after baseline completion
  • Send 14 days before a surgery date
  • Send the next Monday at 9:00 AM after a trigger occurs

When sending based on participant-specific dates, date-validated or datetime-validated fields can be used in the timing options.

Best Practice: If you need a survey sent at a specific time of day, use logic that triggers before the target day and then schedule the send time explicitly, rather than waiting until the exact target day to trigger it.
Important: Calendar/Event dates from the REDCap calendar application cannot be used directly in ASI logic. :contentReference[oaicite:11]{index=11}

Reminders

ASI reminders can be enabled to re-send invitations if the participant has not completed the survey.

  • Reminders are optional
  • They can be configured with their own timing rules
  • The maximum is five sends total: the original invitation plus up to four reminders :contentReference[oaicite:12]{index=12}
Tip: Participants with partially completed surveys can still receive ASI reminders if the survey is not complete. :contentReference[oaicite:13]{index=13}
Important: To stop reminders, first change the ASI so no more reminders are scheduled, then delete any already scheduled reminders from the Survey Invitation Log. :contentReference[oaicite:14]{index=14}

Longitudinal Projects

In longitudinal projects, ASI logic often needs to reference fields from events other than the current event.

When this is the case, prepend the variable with the unique event name:

[unique_event_name][variable_name]

Unique event names can be found in Project Setup → Define My Events.

Important: If you omit the event reference when the field is from a different event, the ASI may not behave as expected.

Re-evaluating ASIs

REDCap includes a Re-evaluate Automated Invitations option that can manually trigger ASI logic to be checked again for existing records. This is useful when:

  • The ASI was created after records already existed
  • Existing records were updated and may now meet the logic
  • You need to catch records that should have had invitations scheduled earlier
Important: Re-evaluating ASIs does not change invitations that are already scheduled. It only schedules invitations that have not yet been scheduled, and may unschedule invitations if the logic is no longer true when “Ensure logic is still true” is in use. :contentReference[oaicite:16]{index=16}
Tip: Re-evaluation is especially helpful for older records, but it should be used carefully in large projects because it can affect many records at once.

Key Limitations and Cautions

  • ASIs do not work with repeating instruments/events
  • ASIs do not retroactively fire for existing records unless re-evaluated
  • Once an ASI fires for a record, changing the logic later does not make it fire again automatically
  • Piped values in the invitation are captured when the invitation is scheduled, not when it is eventually sent
  • Manual invitations and ASIs can both be used, so duplicate outreach is possible if workflows are not carefully designed
Important: If a survey has already been completed, REDCap will not send a scheduled invitation for that already completed survey, even if one had previously been scheduled. :contentReference[oaicite:17]{index=17}

Best Practices

  • Use a dedicated stop-emails or prevent-surveys field as a kill switch
  • Write logic that is readable and testable
  • Test with realistic records before activation
  • Be explicit about timing assumptions, especially when using date and date-time fields
  • Keep reminders intentional rather than automatic by habit
  • Use the Survey Invitation Log to monitor scheduled and sent invitations
  • Document ASI workflows for the study team so everyone understands what is automated and what is manual
Final Takeaway: A successful ASI setup is not just about getting the invitation to send. It is about ensuring the right survey goes to the right person at the right time, under the right conditions, without creating confusion or duplicate outreach.