Piping in REDCap: Injecting Field Values Into Text

Piping is the REDCap feature that lets a form, survey, email, or alert display a value someone already entered, without hardcoding it or asking for it twice. A field label, a piece of descriptive text, a branching-logic condition, or a survey confirmation email can all reference an earlier answer directly. It is one of the more heavily used features in REDCap’s Online Designer, and one of the more common sources of “why is this blank” support tickets when the syntax is slightly off.

The basic syntax: square brackets around a variable name

Piping uses the same bracket notation REDCap uses for branching logic: wrap the variable name in square brackets, [variable_name], and place it inside a field label, field note, section header, or any other descriptive-text area. When REDCap renders that field, it substitutes the bracket expression with the current stored value of the referenced variable for that record.

A simple example: a field named first_name collects a participant’s first name early in the form. A later field label reads Thank you, [first_name] — please confirm your mailing address below. Once first_name has been entered and the form re-renders (or the participant advances to the next survey page), REDCap replaces [first_name] with whatever was typed.

Piping only reads data already stored for that record. It cannot pull a value from a field that appears later in field order on the same page and has not yet been saved — the piped field has to have been entered and saved (or be on an earlier survey page) before the reference resolves.

Longitudinal and repeating projects: the event-name prefix

In a project with multiple events — longitudinal studies, repeating instruments — a bare [variable_name] only looks at the current event. To pull a value from a different event, prepend the event’s unique event name, also in brackets: [unique_event_name][variable_name].

Two details matter here, and both are common failure points:

• The prefix must be the REDCap-internal unique event name (the machine-readable name shown on the Define My Events page, typically lowercase with underscores, e.g. baseline_arm_1), not the human-readable event label shown to data entry staff.
• If the event prefix is wrong, missing where it’s required, or references an event where that field has no data yet, REDCap does not throw a visible error — it silently renders the field as blank (or as the underscore placeholder described below). That silence is what makes a piping mistake easy to miss during design and only get caught after a form has already gone live.

Smart variables: system values, same bracket syntax

Smart variables use identical bracket notation but resolve to system- or project-level information rather than a value a person typed into a field. Common examples include the record’s own ID ([record-id] / [record-name] depending on REDCap version), the current survey link ([survey-url]), today’s date, and the project or event name. Because they share piping’s syntax, smart variables can be dropped into the same label, email, or alert text as regular field piping — a confirmation email can pipe both a participant’s own entered name and a system-generated survey link in the same sentence.

The practical distinction to keep straight when troubleshooting: if a bracket expression isn’t resolving, first check whether it’s meant to be a smart variable (system value, no user data behind it) or a genuine field reference that depends on that field already being filled in for the record.

Piping into survey invitations and confirmation emails

Piping is not limited to on-form text. REDCap’s survey invitation emails, survey confirmation emails, and automated alerts all accept the same bracket syntax, which is how a study sends “Hi [first_name], your next follow-up survey is ready” instead of a generic form letter. The same event-prefix rule applies in longitudinal projects — an invitation for a follow-up event can pipe a baseline-event field, provided the prefix is correct and that baseline field already has a saved value for the record.

This is also where a missing value is most visible to an end user rather than just to study staff: a blank or wrong personalization in a live participant-facing email is a much more noticeable failure than a blank label on an internal data-entry form, which is a good reason to test piped emails against a real test record before a survey goes live, not just preview the form design.

Blank values: the underscore placeholder

If the field or smart variable being piped is blank or has no value yet for that record, REDCap does not simply render nothing — by default it substitutes a row of underscore characters as a visual placeholder, so the surrounding text reads as an obviously-unfilled blank rather than silently dropping a word. Where that placeholder isn’t wanted (for example, optional personalization that should just disappear cleanly when absent), appending :hideunderscore to the variable name inside the brackets suppresses it, e.g. [first_name:hideunderscore].

What can’t be piped, or needs extra care

• Checkbox fields pipe differently than they’re referenced in branching logic. Branching logic against a checkbox requires the per-option (code) form, [field(code)] = '1'; piping a checkbox field instead displays the option label(s) currently checked for that record. Reusing branching-logic’s (code) syntax inside a piping reference is a common cross-contamination error between the two features.
• Circular references — a field that pipes a value from itself, or two fields that pipe each other — don’t resolve to anything useful and should be avoided at design time; REDCap doesn’t attempt to resolve an indefinite loop.
• Un-entered data on the same page, as noted above: piping reads what’s already saved, not what’s currently being typed elsewhere on an unsaved page.
• A hidden field (hidden via branching logic or an action tag) can still be piped — hiding a field from view does not clear its stored value, and that stored value remains available to piping and to data exports alike.

A worked example

A clinical follow-up survey collects a medication name at baseline (baseline_arm_1, field med_name) and needs to confirm it’s still current at each follow-up visit. The follow-up-event field label reads:

At your last visit you reported taking [baseline_arm_1][med_name:hideunderscore]. Is that still accurate?

If med_name was entered at baseline, the follow-up form renders the actual medication name in place of the bracket expression. If, for whatever reason, that baseline field is still blank for this record, :hideunderscore means the sentence simply reads “you reported taking . Is that still accurate?” without a distracting underscore run — a small design choice, but a common source of “why does this survey look broken” reports when it’s skipped.

Frequently asked questions

Does piping work the same way on data-entry forms and on surveys?

Yes — the bracket syntax and resolution rules are the same whether the piped text sits on an internal data-entry form or a participant-facing survey page. What differs is exposure: a piping error on an internal form is caught by study staff, while the same error on a live survey or invitation email is visible to a participant.

Can I pipe a value into a branching-logic condition, not just display text?

Branching logic uses its own comparison syntax ([field] = 'value', with the (code) form for checkboxes) rather than piping’s display substitution — the two features share bracket notation for referencing a field, but branching logic evaluates a condition rather than substituting rendered text. See the branching-logic guide linked above for that syntax specifically.

Why is my piped field showing underscores instead of a value?

The underscore run is REDCap’s default blank-value placeholder: it means the field or smart variable being referenced has no saved value yet for that record (common causes: wrong or missing event prefix in a longitudinal project, the source field genuinely hasn’t been filled in yet, or a typo in the variable name). Append :hideunderscore if a clean disappearance is preferred to a visible placeholder once the underlying data issue, if any, is resolved.

Does piping work across separate REDCap projects?

No — piping resolves against data stored within the same project. Moving a value between separate REDCap projects is an export/import or API task, not something piping’s bracket syntax handles.

Related REDCap and survey-platform guides

• REDCap Branching Logic: Syntax, Testing, and Common Errors — the comparison-condition sibling to piping’s display substitution, including the checkbox (code) syntax referenced above.
• REDCap Data Dictionary: Structure, Editing, and Moving a Project — where variable names, the values piping references, are actually defined.
• The REDCap API: Tokens, Exports, and Automating Data Pulls — for moving data between projects or systems rather than displaying it within one.
• REDCap eConsent Framework: Setup and Regulatory Fit — a common real-world use of piping, personalizing consent-form language with participant-entered identifiers.
• Questionnaire Design: Writing Survey Questions That Work and Survey Question Types: A Practical Guide with Examples — broader survey-design guidance that applies regardless of platform.
• Qualtrics vs REDCap for Academic & Clinical Research — how REDCap’s feature set, including features like piping, compares to the other major academic survey platform.
• REDCap (Research Electronic Data Capture) — the platform-level dictionary entry.