We've annotated some screen shots from a demo project we use in our Survey training to help explain the components of an Automated Survey Invitation. In our survey training, we build out an ASI, and walk through all the elements of the invitation annotated in the screenshot below, as well as demonstrate triggering the ASI by creating a record and entering and saving some data. The material below is intended as reference material.

(info) Need help: We expect most builders will need need help applying the material covered in our training to building out ASIs for the requirements of their study. Sign up for drop-in for help.

ASI Topics

Intended Audience & Prerequisites

Intended Audience

  • Survey project builders

Prerequisite Knowledge & Experience

  • Basics & Survey trainings

  • Working knowledge of the Online Designer and Survey Invitation Log


Big Picture

This is a screenshot of an email invitation set up for a survey that's intended to be sent out to participants every month for 3 months in a row, starting 30 days after the date of enrollment. This is the invitation for month one.

Basic Elements of ASI the Builder Configures

  • Sender
  • Subject line
  • Message
  • Conditions in individual records that REDCap will evaluate to make a determination about scheduling invitations
  • Temporal parameters for defining when the invitations will be sent after the conditions are met
  • Enabling optional reminders
  • Activation

Top Tips

  • Build and test all of your ASI's during the development phase.
    • Adding or editing ASI once you've moved to production and after data collection has started can have unexpected and unwanted effects on your existing records/survey participants that may not be able to be mitigated.
  • Practice canceling your ASI(s) by entering data that makes conditions false.
  • Learn how to use the Survey Invitation log to track invitations that have already been sent and invitations that are scheduled to send in the future.

Email Essentials

  • Add an email validated field to a data entry form to collect your participants' email addresses.
  • Designate the email address collected in that form field for survey invitations via a setting in the Project Setup tab > Optional Modules and Customizations
  • You can configure an invitation to send from the primary, secondary or tertiary email address of any user on assigned to your project.

Closer Look at the Logic Statement in STEP 2: Conditions

This is a screenshot of the logic statement from the invitation above for month one.

Understanding the Logic Statement 

All ASI logic statements are boolean expressions that are evaluated to be true or false. The logic statement in this example is constructed to automate the following two activities:

  • Schedule sending an invitation 29 days after a participant’s date of enrollment.
  • Don't schedule and don't send an invitation if a participant opts out or drops out of study within the 29 day window.

Line by line, the logic is evaluating data in each participant record as follows:

  • The participant's email address has been entered in the form field that's been designated for sending invitations; AND
  • The participant's enrollment status is active; AND
  • The checkbox set up as an invitation kill switch has not been checked; AND
  • It has been at least 29 days since the participant was enrolled in the study.


Connecting the Logic to Data Entry


These are screenshots of the data entry forms that contain the fields that capture the data the logic checks

Understanding the Data Entry Component

By default, data entry activity triggers REDCap to check ASI conditions. This means every time a participant record in your project is created or updated REDCap checks if the data that's been entered and saved to the record meets the conditions defined by the logic statement.

It's important to remember a record can be updated through manual data entry, the participant responding to survey, or through importing data manually or programatically.

Additionally, if a logic statement includes a temporal condition like our example does, via the datediff() function on the 4th line of the statement, REDCap runs additional ASI condition checks about every 10 minutes. 

These ASI condition checks, whether triggered by data entry activity or run by the system to accomodate temporal conditions, will have one of the following outcomes.

  • An invitation is not scheduled because one of the conditions in the logic statement is not true, for example, it's not been 29 days since the participant enrolled.
  • All of the conditions in the logic statement are true and an invitation is scheduled to send out using the the parameters defined in STEP 3 of the ASI, in our example, the invitation would be scheduled send out the next day at 8am.
  • A scheduled invitation that has not yet been sent is removed because the record has been updated in such a way that at least one of the conditions in the logic statement is no longer true, for example, the participant has opted out of completing electronic surveys.





  • No labels