REDCap Branching Logic: A Practical Guide to Dynamic Forms

Control when fields appear based on responses and data conditions

Branching logic allows you to show or hide fields based on participant responses or existing data. It is one of the most powerful tools in REDCap for creating clean, efficient, and dynamic instruments.

Core Principle: Branching logic determines whether a field is displayed. If the logic evaluates to TRUE, the field is shown. If FALSE, the field is hidden.
⚠️ Important: Branching logic is applied to the field you want to show or hide (the destination field), not the field that contains the triggering value.

What Branching Logic Does

  • Shows fields only when relevant
  • Hides unnecessary questions
  • Improves data quality
  • Creates a guided user experience
✅ Best Practice: Use branching logic to reduce cognitive load for participants.

How Branching Logic Flows

At its core, branching logic follows a simple decision path: REDCap checks a condition, then either shows or hides the destination field.

User enters or updates a response
↓
REDCap evaluates the branching logic
↓
If logic = TRUE
The destination field is shown.
[gender] = ‘2’
If logic = FALSE
The destination field stays hidden.
[gender] = ‘1’
Key idea: The logic belongs on the field you want to show or hide. REDCap checks that field’s rule every time the page loads or a triggering value changes.
Example: If you only want to show a pregnancy question when the response to sex is Female, the pregnancy field would contain the branching logic, such as [sex] = '0' if Female is coded as 0.

How to Set It Up

  1. Go to Online Designer
  2. Edit a field
  3. Enter logic in the Branching Logic box
  4. Or use the logic builder
Tip: Use the builder first, then refine manually.

Logic Syntax

Basic format:

[variable] = 'value'

Examples:

[gender] = '1'
[age] > 18
[consent_complete] = 2
[field_name] <> ""
⚠️ Important: Use “” (no space) to check for blank values.

Simple vs. Complex Branching Logic

Branching logic can range from very simple conditions to more complex, multi-part rules. Understanding how logic builds step-by-step makes it much easier to write and troubleshoot.

Simple Logic

One condition controls whether the field appears.

[gender] = ‘2’

➡ Show field only if gender = Female

Use case: Basic eligibility or demographic filtering

AND Logic

All conditions must be TRUE.

[age] > 18 and [consent] = ‘1’

➡ Show field only if BOTH conditions are met

Use case: Eligibility + consent requirements

OR Logic

Only one condition must be TRUE.

[symptom1] = ‘1’ or [symptom2] = ‘1’

➡ Show field if ANY condition is met

Use case: Trigger follow-up questions

Complex Logic (Grouped Conditions)

Use parentheses to control how logic is evaluated.

([q1] = ‘1’ or [q2] = ‘1’) and [q3] = ‘2’

➡ Show field if (q1 OR q2) AND q3 is true

Key Tip: Without parentheses, REDCap may evaluate logic in an unexpected order.

Checkbox Logic Example

Checkboxes require special syntax for each option:

[symptoms(1)] = ‘1’ or [symptoms(2)] = ‘1’

➡ Show field if either checkbox option is selected

⚠️ Important: Each checkbox choice is its own variable—do not treat it like a dropdown or radio field.
✅ Best Practice: Start simple. Build and test one condition at a time, then layer additional logic.

Checkbox Logic

Checkboxes use special syntax:

[field(1)] = '1'   → checked
[field(1)] = '0'   → unchecked
⚠️ Important: Each checkbox option is its own variable.

Building Complex Logic

([q1] = '1' or [q2] = '1') and [q3] = '2'
Tip: Always use parentheses for clarity.

Longitudinal Considerations

[baseline_arm_1][weight]
  • Reference events explicitly
  • Test across events
⚠️ Important: Branching logic is NOT event-relative by default.

Limitations

  • Cannot hide entire instruments
  • Cannot skip surveys
  • Works only at field level

Common Mistakes

  • ❌ Applying logic to wrong field
  • ❌ Treating checkbox like radio
  • ❌ Forgetting quotes
  • ❌ Not testing with real data
Common Mistake: Assuming preview mode fully tests logic.

Common Real-World Examples

Branching logic is most useful when it mirrors how people actually move through a form or survey. Below are some common ways it is used in real REDCap projects.

Eligibility Screening

Only show follow-up eligibility questions if the participant meets initial screening criteria.

[age] >= 18 and [consent_interest] = ‘1’

Use case: Recruitment and screening forms

Sex-Specific Questions

Only display fields when they are relevant to the participant.

[sex] = ‘2’

Use case: Pregnancy history, prostate-related questions, etc.

“Other, Specify” Fields

Show a text box only when a participant selects “Other.”

[race] = ’88’

Use case: Dropdown or radio fields with an “Other” choice

Medication Lists

Show the next medication field only when the previous one has been completed.

[med1] <> “”

Use case: Repeating-like entry without repeating instruments

Symptom Follow-Up

Show severity or details only if a symptom is present.

[symptom_present] = ‘1’

Use case: Adverse events, symptom screens, clinical intake

Checkbox-Based Follow-Up

Show additional questions if one or more checkbox options are selected.

[symptoms(1)] = ‘1’ or [symptoms(2)] = ‘1’

Use case: Multi-select symptom or exposure lists

Design Tip: Branching logic works best when it follows the natural decision process of the user. If the logic feels hard to explain in plain language, it is often worth simplifying.
✅ Best Practice: Write down the plain-English rule first, then convert it into REDCap logic. For example: “Show this field only if the participant is over 18 and consented.”

Best Practices

  • Keep logic simple
  • Use consistent coding
  • Test thoroughly
  • Use parentheses