By default, new projects will use the 'classic' data collection format, which is the best option if all data collection instruments will only need to be used once for each record in the project. If some instruments need to be utilized repeatedly a specific *finite* number of times (e.g., using an instrument named 'Visit Data' over ten visits for the same subject), then 'longitudinal' data collection will likely be best. Additionally, the longitudinal format also allows one to utilize the scheduling module, if needed.

Are you sure you wish to disable longitudinal data collection? If you do so, please note that all your arms and events that you have created thus far will become hidden and will no longer be accessible. If you have collected some data already, only the data collected for your first event (on the first arm) will remain. If you wish to enable longitudinal data collection again, all your events and any data collected on them will return.

After creating data collection instruments in the steps below, you and other users in this project may enter data for those instruments. Additionally, you may enable any instrument as a survey and then collect data for that instrument from survey respondents. The only difference is who will be entering the data: project users, survey participants, or both. For surveys, you may utilize a Participant List for emailing your recipients and also to track who has taken your survey(s). And if your first data collection is enabled as a survey, then you may use a public survey link, which is a single link that can be emailed to all participants or even posted on a website.

Are you sure you wish to disable the usage of surveys in this project? If you do so, please note that all your surveys that you have created thus far will become hidden and will no longer be accessible. Your data collection instruments will remain just as they are, but they will simply not be able to be utilized as surveys. If you wish to enable the use of surveys in this project again, all your surveys that you had previously created will return.

This option will remove the ability for users to name new records manually and will instead provide a link that will auto-generate a new unique record name, which will be numerical and will increment from the highest numerical record value in the project. If no records exist, it will begin with '1'.

The scheduling module can generate schedules for your project calendar that are auto-generated from project-defined events (e.g., visits, time-points). Scheduling is only available for projects using longitudinal data collection.

Randomization is a process that assigns participants/subjects by chance (rather than by choice) into specific groups, typically for clinical research and clinical trials. The randomization module in REDCap will help you implement a defined randomization model within your project, allowing you to randomize your subjects (i.e. records in your project). In this module, you first define the randomization model with various parameters. Based on the defined parameters, the module creates a template allocation table, which you can use to structure the randomization table you will import. The module also monitors the overall allocation progress and assignment of randomized subjects.

User privileges can be set to allow only certain users to be able to set up the randomization, perform the randomization, or view the allocation dashboard to view progress. If someone is given 'Randomize' privileges, they will be able to view and modify any existing data already collected for the randomization strata fields (if stratification is used) when they are performing the randomization, even if they do not specifically have form-level rights to view the form on which a strata field exists. Thus Randomize rights trumps form-level rights in this way, but only for the randomization strata fields.

By enabling this feature, REDCap can direct specific email communications to the email address provided. This includes sending survey invitations, automated survey invitations, survey confirmation emails, and Alerts & Notifications. If a field is designated for that purpose, then any records in your project that have an email address captured for that particular field will have that email address show up as the participant's email address in the Participant List (unless an email address has already been entered for that participant in the Participant List directly).

Using the designated email address field can be especially valuable when your first data collection instrument is not enabled as a survey while one or more other instruments have been enabled as surveys. Since email addresses can only be entered into the Participant List directly for the first data collection instrument, the designated email field provides another opportunity to capture the email address of survey participants.

Please be aware that designating an email field means that survey responses can NEVER BE ANONYMOUS because of the fact that the participant's email address can be viewed on a data entry form, which means it is easy to identify the record/response to which the email address belongs.

NOTE: If the participant's email address has already been captured directly in the Participant List, then that email address will supersede the value of the email field here when survey invitations are sent to the participant. Also, if the email invitation field exists on multiple longitudinal events, on a repeating instrument, or on a repeating event, the field's value will be synchronized across all instances/events so that changing it in one location will change the value across all events/instances where the field appears.

Survey-specific email invitation field: While the email invitation field discussed here is a project-level setting, it is helpful to know that there also exists a survey-level email invitation field option that can be utilized for particular surveys in the project (whereas the project-level field would be applied to ALL surveys). A survey-specific email invitation field can be enabled for any given survey, in which you can designate any email field in your project to use for sending survey invitations for that particular survey. Thus, you can collect several email addresses (e.g., for a student, a parent, and a teacher) and utilize each email for a different survey in the project. Then you can send each person an invitation to their own survey, after which all the survey responses get stored as one single record in the project. See the 'Survey Settings' page in the Online Designer for this survey-level setting.

The Data Entry Trigger is an advanced feature. It provides a way for REDCap to trigger a call to a remote web address (URL), in which it will send a HTTP POST request to the specified URL whenever *any* record or survey response has been created or modified on *any* data collection instrument or survey in this project (it is *not* triggered by data imports - including API imports and Mobile App imports - but only by normal data entry on surveys and data entry forms). Its main purpose is for notifying other remote systems outside REDCap at the very moment a record/response is created or modified, whose purpose may be to trigger some kind of action by the remote website, such as making a call to the REDCap API.

In the HTTP Post request, the following parameters will be sent by REDCap in order to provide a context for the record that has just been created/modified:

Are you sure you wish to disable the usage of MyCap in this project? If so, please note that all your MyCap task settings and configuration that you have created thus far will become hidden and will no longer be accessible. Your data collection instruments will remain just as they are, but they will simply not be able to be utilized by MyCap. If you wish to enable the use of MyCap in this project again, all your MyCap tasks settings and configuration that you had previously created will return.