REDCap Branching Logic: Syntax, Testing, and Common Errors

REDCap branching logic decides, field by field, whether a question is shown to whoever is entering data — a survey participant, a research coordinator, a data manager — based on the value already entered somewhere else in the project. It is the mechanism behind every REDCap form that skips irrelevant questions, reveals a follow-up field only when a prior answer calls for it, or hides an entire section of a case report form until an earlier gate condition is met.

The syntax is small and mostly forgiving — until it isn’t. Branching logic that references the wrong thing does not throw an error. The field it controls simply never appears, or appears when it shouldn’t, and REDCap gives no indication that anything is wrong. This guide covers the actual syntax rules, the handful of reference patterns that account for nearly all silent failures, and how to test logic before it reaches a live project.

What branching logic actually controls

Branching logic is evaluated live, in the browser, every time a value on the form changes. When the logic attached to a field evaluates to true, the field (or, if it’s set at the section level, the whole section) becomes visible and — if marked required — enforces that requirement. When it evaluates to false, the field is hidden and any requirement is suspended.

That is the entire scope of what branching logic does. It does not check whether a visible field’s entered value is well-formed — that is field validation, a separate mechanism. It does not run as a batch check across existing records — that is the Data Quality module. And it does not alter or clear stored data on its own. Keeping these three mechanisms distinct matters, because most “branching logic isn’t working” reports turn out to be one of the other two doing exactly what it was configured to do.

Core syntax: field references, operators, and quoting

A field is referenced in square brackets using its underlying variable name, not its on-screen label: [age] >= 18. Comparison operators are =, <> (not equal — REDCap does not accept !=), <, >, <=, and >=. Logical combination uses the words and / or, not && / ||, and parentheses control precedence exactly like any other expression language — without them, a mixed and/or condition can evaluate in an order you didn’t intend.

Text and date values being compared are quoted: [enrollment_date] > '2026-01-01'. Numeric and coded values generally are not: [consent_given] = 1. The value on the right side of the comparison must always be the underlying stored code, never the label printed on the form — this single distinction is the source of most branching logic that looks correct on the page and does nothing when saved.

Checkbox fields need the (code) form — the most common branching-logic error

A REDCap checkbox field is not one variable with several stored values; it’s a separate binary sub-variable per option, each independently either checked (1) or unchecked (0). Branching logic has to reference the specific option, not the field name alone: [symptoms(3)] = '1' targets option code 3 of the symptoms checkbox field specifically, and evaluates true only if that exact box is checked.

Writing [symptoms] = '3' — the pattern that works correctly for a radio button or dropdown field — does not raise a syntax error on a checkbox field. It simply compares a field that has no single value against a value it can never equal, so the condition is always false. The dependent field never appears, in development or in production, and because nothing about the save succeeded or failed, there’s no error to notice. This is, by a wide margin, the error people run into first: it happens the moment someone copies logic syntax from a radio field to a checkbox field, or writes checkbox logic from memory without opening the field’s own reference syntax in the Online Designer.

Radio, dropdown, and yes/no fields: compare to the code, not the label

Radio buttons and dropdowns are referenced directly — [referral_source] = '2' — where 2 is the coded value assigned to a specific choice in the field’s option list, not the text a person reading the form sees. Yes/No fields store 1 for Yes and 0 for No underneath a Yes/No display, so logic still compares against 1 or 0, never the words themselves.

Because logic is anchored to the numeric code rather than the label, relabeling a choice later (fixing a typo, clarifying wording) does not break existing branching logic. Renumbering or removing a choice code that logic already depends on does — and REDCap will not warn you when you edit the choice list that a field elsewhere in the project references the code you just changed.

Cross-instrument logic within the same event

Fields don’t have to live on the same instrument (form) to reference each other. Within a single event, every instrument’s data belongs to the same underlying record, so a field on Instrument B can reference a field on Instrument A by name with no special syntax: [intake_bmi] >= 30 works identically whether both fields are on the same form or different ones.

The practical catch is sequencing, not syntax. If Instrument A hasn’t been completed and saved yet for that record, the field it would supply is still blank as far as the logic is concerned, so any condition depending on it evaluates false — not because the reference is wrong, but because the data it depends on doesn’t exist yet at that point in the workflow. This matters most in single-session survey queues where instruments are meant to be completed in a specific order; branching logic that depends on an earlier instrument assumes that instrument was actually submitted first.

Longitudinal projects: event-prefixed field references

In a longitudinal or repeating-event project, a bare field reference only looks within the current event. Pulling in a field defined on a different event requires prefixing it with that event’s unique event name: [baseline_arm_1][weight] > 90 references the weight field as captured specifically at the baseline_arm_1 event, from a field defined anywhere else in the project.

Two details cause this to fail quietly. First, the bracketed prefix has to be the project’s internal unique event name (visible on the Define My Events page), not the human-readable event label shown to data entry staff — the two commonly differ once a project has been renamed or restructured. Second, omitting the prefix entirely when the field genuinely lives on a different event doesn’t produce an error; REDCap looks for a same-named field on the current event, doesn’t find one, and treats the reference as blank — so, like the checkbox case above, the condition is simply always false and the dependent field never displays.

Branching logic is not the same as field validation

Branching logic and field validation solve two different problems and are configured in two different places on a field. Branching logic decides whether a field is shown at all. Validation (REDCap’s Text Validation types — integer, number, date, email, and so on, each with its own optional min/max range) decides whether a value already being entered into a visible field is well-formed. A field can have perfectly correct validation and still be logically wrong to be showing at all for a given record, and a field can be exactly where it should be, logic-wise, while still accepting a malformed value if its validation type is too loose or absent.

The interaction that trips people up most: hiding a field with branching logic does not clear or lock the data already stored in it. If a field was visible and answered earlier — before branching logic was added, or before an earlier answer changed — and a later condition then hides it, the previously entered value is still sitting in the database and will still appear in a data export, even though nobody looking at the form today would ever see that question. In a project subject to 21 CFR Part 11 or similar audit requirements, that gap between “what the form currently shows” and “what the export currently contains” is worth designing around deliberately rather than discovering during a data-cleaning pass.

Testing branching logic before it reaches production

REDCap’s field-level branching logic editor (in the Online Designer) offers two ways to build a condition: a guided “drag-and-drop” builder that assembles valid field/operator/value syntax without free text, and a raw logic text box for conditions the builder can’t express — multi-field boolean combinations, cross-event references, and anything using the (code) checkbox form. The guided builder is the safer default for straightforward single-condition logic specifically because it can’t produce a malformed field reference; reserve the raw text box for logic that genuinely needs it, and proofread that syntax by eye against the field’s real variable name and option codes rather than typing from memory.

Before moving a project (or a change to an existing project) into production, walk through the instrument or survey end-to-end as a test record with representative values for each branch — including the values meant to keep a field hidden, not only the values meant to reveal it. A field that correctly shows under the “happy path” input can still be silently broken for the input that was supposed to suppress it, and that direction is easy to skip when testing focuses on making sure content appears rather than confirming it also disappears when it should. For an entire project at once, exporting the Data Dictionary (the codebook) puts every field’s branching logic in one spreadsheet column, which is a faster way to audit logic across dozens of fields than opening each field individually in the Online Designer.

A quick troubleshooting checklist

When a field isn’t showing or hiding the way it should, check these in order — they account for nearly every case:

• Is the target a checkbox field referenced without the (code) form? ([field] instead of [field(code)].)
• Is the comparison value the label text instead of the underlying stored code?
• In a longitudinal project, is a cross-event reference missing its [event_name] prefix, or using the display label instead of the internal unique event name?
• Does the field being referenced actually have saved data yet for this record — is this a sequencing problem, not a logic problem?
• Is a mixed and/or condition missing the parentheses needed to force the intended grouping?
• Is != being used anywhere instead of REDCap’s <>?

Frequently asked questions

Why is it called “branching logic” instead of “skip logic”?

They describe the same underlying idea — showing or hiding questions based on prior answers — that questionnaire design more generally calls skip logic or display logic. “Branching logic” is simply REDCap’s own name for its implementation of the concept, tied to its specific field-reference syntax.

Can branching logic reference a field on a different instrument?

Yes, within the same event, with no special syntax — REDCap treats all of a record’s instrument data for a given event as one pool of fields. The dependency that matters is sequencing (has the referenced instrument actually been saved yet), not which form the field lives on.

Does hiding a field with branching logic delete the data already in it?

No. REDCap does not clear or lock a field’s stored value when branching logic later hides it. The value remains in the database and in exports even though the form no longer displays the question.

What’s the difference between branching logic and the Data Quality module?

Branching logic runs live, per field, in the browser, and controls visibility as data is entered. The Data Quality module runs on demand or on a schedule against records already in the project, flagging data that fails a defined rule — a check for data that’s already there, not a control over what’s shown during entry.

Can I use “is not equal to” in branching logic?

Yes, but the operator is <>, not !=. Using != is a common transfer error from general-purpose programming languages and does not work in REDCap’s logic syntax.