REDCap Tips

Welcome to REDCap Tips! Here you'll find posts about features you may not have discovered, little-known "tricks", and other things that come up now and then, but may not be covered in the Help & FAQ in REDCap. Check back periodically to see if any new tips have been uploaded!

Tip #34

You can use conditional logic in your database by using an "if/then" statement in calculated fields. See the Help and FAQ page for details.

Tip #33

If you have multiple instruments that you want to send out as a single survey, combine them onto a single REDCap form. You can insert page breaks between instruments using the Section Header field type.

Tip #32

REDCap allows you to customize field labels or survey invitations using "piping". This means you can insert the response to one field, e.g. first name, into the label of another field or into a survey invitation text. To do this, just put the variable name in square brackets where you want the customized text. For example, if the respondent's first name is in a variable called "fname", you can add it to the label of another field like this: [fname], what is your favorite color? Similarly, when you write a survey invitation, you can use: Dear [fname], please complete the attached survey. Whatever name has been entered in the field fname will appear in place of the variable name.

Tip #31

When setting up a Longitudinal project event grid, if you are not using the Scheduling module, you don't need to set specific "days offset", but you still need to enter something to tell REDCap the order of your events. If you leave all zero's, REDCap will put your events in alphabetical order. So, you can just put 1, 2, 3 etc. You may also want to use increments of 5's in case you later need to insert a new event.

Tip #30

Using the "automated invitations" feature, you can schedule survey to be sent at a specific date/time as well as based on a specific response to a previous form or survey. See detailed instructions on how to do this in the Help/FAQ page.

Tip #29

Section header fields follow the branching logic for *all* fields until the next section header, so to hide a section header, all fields until the next section header must also be hidden.

Tip #28

REDCap allows some customization of form appearance using HTML code. These include font size, font color, and spacing/indentation of field label text.

Tip #27

There is a visual cue to tell you whether a field is a radio button (single option) or a checkbox (choose all that apply). Radio buttons are round, checkboxes are square.

Tip #26

When you move your project from Development to Production, you have the option of keeping or deleting any exisiting records. NOTE: the default setting is to delete any records, because the assumption is that they are dummy data for testing. Be sure to UNCHECK the option if you want to keep your data. Your choice will be confirmed in the form you complete prior to moving to Production.

Tip #25

Checkbox, or "choose all that apply", fields are coded slightly differently from other categorical fields, such as radio or dropdown. In those, each option is set to equal a unique value, e.g. 1=red, 2=blue, 3=green. Because any or all of the checkbox field options can be selected, each option is treated as a separate field that is either checked or unchecked (coded 1 or 0). In your exported dataset, you will see that each option has become a separate variable with the number of the option as part of the variable name, e.g. color(1), color(2), color(3). When using options from a checkbox field in a calculation or in branching logic, instead of writing "color = 3", for example, you need to write "color(3)=1", meaning that option 3 of the variable "color" has been selected.

Tip #24

Project changes made after moving to production must be reviewed prior to being implemented to reduce the risk of data corruption due to a change. However, if you make a change that cannot possibly impact existing data (e.g. create a new field), once you submit the change for approval, it will be approved automatically - you won't have to wait for manual review and approval by the administrator. To view whether you changes create potential issues, while you're in draft mode, go to the "view a detailed summary of all drafted changes" link.

Tip #23

If your categorical variable has numeric response options, be sure to assign a value that is the same number to avoid confusion in analysis. For example, if the question is "How many times did you ....", and the options are 0,1,2,3,4,5, you should assign values of 0-5 (note: you cannot use the auto-assign feature of REDCap because it will start with 1).

Tip #22

Anyone creating projects should attend a tutorial (see schedule on Tutorials page) which focuses on project creation and REDCap use policies. If you have attended a tutorial, you can request limited accounts for others who will not be designing/managing projects, but only doing data entry, data export, etc. To request an account, email the REDCap administrator with the person's name and work email address. By doing this, you are also taking responsibility for training them.


If you are including survey responses in a calculation but don't want the respondent to see the calculations, create a separate data entry form and put the calculation fields there. The calculations will be triggered when the survey is submitted.

Tip #20

When using a greater than/less than (>,<) condition in branching logic, don't put quotation marks around the value, as you normally would when using equal to.

Tip #19

If you are concerned that survey respondents changed their answers before submitting their survey, e.g. to try to qualify for a study, you can check their responses in the Logging Tool.

Tip #18

You can use the logging tool to troubleshoot issues that arise that may be due to a change in a data value, calculations and branching logic no longer working, etc. In the log, you can filter by record, user, and event type.

Tip #17

Use dropdown field types instead of radio buttons for categorical variables on your data entry forms. REDCap allows you to type the first character of a label to select that option in a dropdown, which is much easier than having to individually select each radio button with your mouse.

Tip #16

To test branching logic or calculated fields, enter a test record into your database or survey. These functions do not work on the Preview screen. You can remove all test records when you move to production.

Tip #15

If you are using calculated fields, avoid creating second-level calculations, i.e. using the results of a calculation as part of another calculation. These fields will not reliably calculate - even though values may appear in the field onscreen, the field may be blank in your exported dataset. Keep in mind the general recommendation to do calculations as part of analysis, and keep only raw data in your REDCap database.

Tip #14

You can track who has responded to a survey by using the Participant List option. In addition, you can identify individual responses using the Participant Identifier feature. Both of these options are found in the Manage Survey Participants section of your project.

Tip #13

If you are using online surveys, you can schedule them to be sent automatically at certain dates, or based on specified conditions being met. See Automated Invitations in the Online Designer for instructions.

Tip #12

When creating a survey, you must complete the “Modify Survey Settings” section to activate the survey url.

Tip #11

To include an "Other" option in a multiple choice question that will allow respondents to write in an answer, add a text field that is only displayed when the Other option is selected.

Tip #10

In a Longitudinal Model database, if you accidentally delete an event, your data will not be lost, just hidden. When you restore the event with the assigned forms, the data will also be restored.

Tip #9

It's a good idea to test your database or survey before moving to Production by entering a few records of either real or fake data. When moving to Production you can choose to keep or delete these records.

Tip #8

To display an image on your data entry form or survey, use the descriptive text field type which has a filed upload feature.

Tip #7

If your project is in production and you need to make several changes, consider making a copy of the project (which will be in development), making the changes there, then using the data dictionary to implement the changes all at once in the production project. Alternatively, you can ask the REDCap administrator to move your project back to development.

Tip #6

It is now possible to edit or delete survey responses. To do this, check the Edit Surveys option in the User Rights section.

Tip #5

Before submitting post-production changes for review, you can see whether they will cause any problems by selecting the "view a detailed summary of all drafted changes" link located next to the Submit Changes for Review button.

Tip #4

If you add a calculated field after you have collected the data used in the calculation, you will need to resave the form containing the calculation to trigger REDCap to perform the calculation and populate the field.

Tip #3

When you set up a REDCap database, your record identifier, e.g. Participant ID, must be the first field on the first form so that REDCap will link all following data on all forms for that record. There is no need to repeat the record identifier in each form.

Tip #2

To make your data entry screen bigger, click on the vertical line dividing the left panel showing your forms and applications from the main data entry area. This will hide the left panel so that the data entry section takes up the entire screen.

Tip #1

Although you can make changes to your project fields after moving your project to Production, keep in mind that changes to coding for categorical fields will impact your existing data. For example, if you have a field with Yes/No responses that are coded 1,0 and you change these to 2,1 then what was originally coded as Yes will now be No - since you have changed the meaning of the value 1.