Automated Survey Invitations (ASI)

Initial Considerations 

Automated survey invitations allows a survey to be scheduled and automatically sent to a participant. 

Triggering an ASI is based on specific conditions or logic.  The triggers consist of a participant completing another survey in your project, and/or custom logic.  There are several options for specifying the time in which the survey invitations get scheduled after being triggered. 

To stop the invitations from being sent out, the Automated Invitations setting can be set as “Not Active” at any time. This will stop the ASI from firing for all participants in the project. 

The Process 

To set up Automated Invitations, do the following:

1. Enable an instrument to be a survey.  Instructions on how to enable a survey, click here: Enable Survey 

2. Go to "project setup" and click on "Online Designer" 

3. On the "Data Collection Instruments" table, click on “+Automated Invitations” that's located next to the survey you want to send out (circled in red in image below)
   
   
   

   Open

   

4. An "Automated Invitations” box similar to the one shown below will then pop-up. 

   Select “+ Set up” next to the visit you would like to schedule the invitation for. If you are using longitudinal settings, all relevant events will appear in this list.
   
   

   Open

   

    

5. Next, a box pops up that is used to define what conditions need to exist enable for the survey to be sent.   Go through the steps to program the Automated Survey Invitation.  The steps are the following:
   
   

   1. Step 1 - What the survey invitation message should say. Ensure you do not remove the "[survey-link]" component of the message as this is how the ASI links to the survey. 

   2. Step 2 - Select or enter what conditions need to be met before the survey is sent (e.g. select an instrument that needs to be completed or enter logic that needs to be true, such as [age] > 30)

   3. Step 3 - Select how soon to send it after conditions are met. Here you can set the ASI to send so many days/hours/minutes after or before it is triggered, or based on another field in the project such as a date field. 

   4. Optional: Enable reminders - You can also set the ASI to re-send the survey if it has not been completed by a certain time.  To do this, Enable the reminders, select when to re-send it, and select the number of times you would like it to be resent.

   5. Step 4: To inactivate the survey, click on “Not Active” at the bottom of the box. To activate the ASI so it is "live", click "Activate" 

   6. Click “Save”
      
      

6.   The survey will now be set to automatically send out invitations.  I suggest you test it out before moving your project to production

ASI Best Practices 

• Ensure your ASI is based on logic from instruments that are listed before the ASI configured survey in your project. 

• When configuring your ASI, ensure your "From" sender is selected as the correct email. 

• If your project is utilizing Twilio, ASIs can be sent via email or SMS. Ensure this option is selected in the setting that appears before "STEP 1" 

• Do not copy and paste text from files into the ASI message as the styling will come across and cause truncation of your ASI. 

• Always ensure your logic is "Valid" before activating an ASI and test thoroughly. The "Valid" notice will appear at the bottom of the Logic Editor in green. 

• Always re-evaluate ASIs when you make any edits to the ASI. You can re-evaluate by clicking "Re-Evaluate Auto Invitations" towards to the top right of the online designer page. Make sure you only have selected the ASI(s) you edited and not all ASIs. 

• Review any scheduled ASIs in the Survey Distribution Tools tab on the left side of REDCap and click Survey Invitation Log to view all scheduled and past ASIs. 

• Enable the option "Ensure logic is still true before sending invitation?" for every ASI to allow the system to check whether the ASI should still be sent prior to sending. If this is not enabled, once an ASI is scheduled, it will not unschedule even if the record no longer qualifies to receive the ASI. 

• Improvement: When deleting an invitation from the Survey Invitation Log (either as a single invitation or using the multi-select option to delete many invitations at once), it now provides a new option in the dialog prompt to "Permanently cancel this invitation?", in which the phrase "permanently cancel" implies that the invitation cannot be re-triggered/scheduled again in the future even if the ASI conditions are met again. If the user chooses to uncheck the option, then the scheduled invitation will be removed, but could possibly get re-triggered in the future if the ASI conditions are met again (assuming it was originally scheduled via an ASI).

Reminders 

• When you re-evaluate ASIs, any edits to the body of the message will not change for any ASIs that are already scheduled. 

• Remember to test all ASIs for all conditions, arms, events, and preferred delivery method. 

Additional Considerations

Stop Logic 

How to activate 

Step 1

Create a field in an instrument that appears before the instrument attached to the ASI. Best practice is to add this field in the very first instrument to ensure it falls before any ASIs in the project. This field should be a simple Yes/No field as shown below and a default action should be assigned. For the field in this example, the default action tag is set to "No" (@DEFAULT='0'). 

Step 2

Add the stop logic to all ASIs that are active. To add stop logic, you first open the ASI settings and in "Step 3" of this window, open the Logic Editor and add the logic for the stop logic. For this example our logic would be:

[stop_logic]='0' 

Ensure you append the variable with the arm label if using arms in your project. 

We want the ASIs to fire only when our field variable is set to "No" because no stop logic is needed. 

Step 3

Ensure you enable the "Ensure logic is still true before sending invitation?" option below the Logic Editor otherwise the stop logic will not function as needed. 

By enabling this option, it allows REDCap to evaluate an ASI condition before firing it after it has already been scheduled. If an ASI is scheduled and then we change the stop logic field to "Yes", then REDCap will unschedule any ASIs for that participant. 

Step 4

To use the stop logic we simply go into the record that needs to stop receiving any further ASIs and change this field answer to "Yes". Remember, by using the action tag, every participant will be defaulted to "No" unless changed by the study team. 

Changing the Date of a scheduled ASI:

If it is necessary to change the date of an ASI that has already been configured, follow these directions:

• 1) Deactivate the ASI adding to the condition-logic a condition which cannot be true (ie [varx]=999 where [varx] have as possible value only 1 or 2)

• 2) Then re-evaluate the ASI --> All ASI should be deleted (check it in the survey distribution tool)

• 3) Set again the ASI with the new date and adjusting again the condition-logic

• 4) re-evaluate the asi once again

Changing the content of a scheduled ASI:

When you re-evaluate ASIs, any edits to the body of the message will not change for any ASIs that are already scheduled. 

• If you create or edit an ASI after data collection has started, you will need to resave records to have the ASI logic evaluated—REDCap will not go back and automatically check all records to see if any meet the new/updated logic. If an invitation has already been scheduled for a record, but not sent, the invitation wording and scheduling will not be changed to reflect new wording/logic.