Written and maintained by CASRAI Editorial Board
Last updated
REDCap’s Randomization module assigns each enrolled participant to a study arm — treatment vs. control, or one of several arms — the moment a designated trigger field is saved. What it does not do is generate the sequence of assignments itself. That distinction drives almost everything else about how the module is set up, and it is the most common source of confusion for a research coordinator setting it up for the first time.
What the Randomization module actually controls
Once enabled, the module watches a specific “trigger” event on a specific form or survey. When that event fires — the form is saved, or (for a survey) the participant submits — REDCap looks up the next available row in a pre-loaded allocation table, writes the assigned group into a designated target field, and marks that row of the table as used so it is never assigned again. The target field then becomes system-controlled: it is not manually editable from the data entry form, which is the whole point — it keeps a coordinator from being able to see or override an assignment before it happens, or after.
This is a different mechanism from branching logic, which only shows or hides fields based on values already entered, and from a calculated field, which derives a value from a formula. Randomization assignment is neither shown/hidden nor computed — it is looked up from a table that was built and uploaded before the study opened.
REDCap doesn’t generate the sequence — you do, outside REDCap
This is the part that surprises people expecting a “click to randomize” button: REDCap has no built-in random-sequence generator for the allocation table itself. The table has to be produced outside REDCap — in R, SAS, Stata, or even a spreadsheet with a random-number function — typically by the study’s statistician, and then uploaded as a CSV. REDCap’s role starts after that: it stores the table, walks it in order for each stratum as participants enroll, and enforces that a row is never reused.
Practically, the standard build pattern is: generate one row per intended enrollment slot, assign a random value to each row (a spreadsheet rand() column, or the equivalent in your statistical package), sort the table by stratum and then by that random value, and only then remove the random-value column before saving as the final CSV. The column has to be dropped before upload — REDCap doesn’t care that it was used to build the order, but leaving a stray random-number column in the uploaded table is a common source of an allocation table that fails validation on upload.
Building the allocation table
The Randomization Setup page offers a downloadable template CSV — start from that rather than building the column structure from scratch, since the module validates the uploaded table’s headers against exactly what it expects. At minimum the table needs one column per stratification factor (matching, by underlying coded value, the corresponding REDCap field) and one column holding the group assignment for that row. Every possible combination of stratum values you intend to use needs enough rows to cover expected enrollment in that stratum — if a stratum runs out of unused rows before enrollment ends, randomization for new participants in that stratum fails outright, which is why over-provisioning each stratum’s row count is standard practice, not a nice-to-have.
Stratifying the allocation
Randomization can be stratified by any categorical field already in the project — sex, age band, disease severity, treatment site — and, separately, by Data Access Group (DAG), which is the standard mechanism for a multi-site study to randomize independently within each site rather than pooling assignment across sites. Both approaches are configured on the same Randomization Setup page: a stratification field is picked from the project’s existing fields, or DAG-based stratification is turned on directly.
The trade-off scales badly if it’s ignored: every additional stratification variable multiplies the number of distinct strata, and each stratum needs its own adequately sized block of allocation-table rows. A two-arm study stratified by three binary factors already has eight strata to provision for — adding a fourth factor without revisiting table size is a common way small-enrollment sites end up mid-study with an exhausted stratum and no valid next assignment.
Blocking, so arm sizes stay balanced throughout enrollment
Simple randomization within a stratum can still drift — arm sizes can end up meaningfully uneven partway through enrollment purely by chance, especially in a small stratum. The standard fix, and the reason allocation tables are normally built in blocks rather than as one long randomized list, is permuted block randomization: the table is constructed in small blocks (e.g., blocks of 4 or 6) within each stratum, each block containing a balanced mix of arms in random order. Balance is then guaranteed at every block boundary, not just at the end of the study, which matters for a trial that might stop enrolling early or analyze results at an interim point.
Enabling randomization and the production-status lock
Randomization setup is done while a project is still in Development status. Once a project moves to Production, the Randomization Setup page locks — the trigger field, target field, and stratification configuration all become unchangeable through the normal interface, and this is by design, not a bug to work around casually: it exists to protect the integrity of an allocation scheme once real participants may already have been assigned from it. A subset of settings (strata weightings, allocation ratios, base allocation probability) technically stay editable in Production only for as long as zero records have actually been randomized yet — once the first real assignment happens, that window closes too.
If a genuine correction is needed after that point — the wrong table was uploaded, or the design has to change — the only path is to reset the randomization module, which requires deleting the existing allocation table and configuration and rebuilding it from scratch. Because that action affects already-collected data integrity, back up the project first and treat a reset as a rare, deliberate, documented event, not a routine fix.
Blinding: randomization access is its own user right
Seeing a participant’s assigned group is gated by a dedicated “Randomization” permission in REDCap’s User Rights, separate from every other project permission a user might hold. A coordinator can have full data-entry rights on a project and still be correctly blocked from viewing the allocation table or any participant’s assigned arm if that specific right isn’t granted — which is what makes the module usable for genuinely blinded or double-blind designs, not just open-label ones. Get the rights assignment wrong (granting Randomization access to someone who is supposed to be blinded) and there is no technical safeguard left to catch it; it is a study-design control enforced through project setup, not something REDCap infers automatically from role.
Common setup mistakes
- Uploading a table with the
rand()/random-value column still attached. Sort by it, then delete it — REDCap expects only the stratum and assignment columns. - Under-provisioning a stratum. Adding stratification factors without recalculating how many allocation-table rows each resulting stratum needs is the single most common reason randomization fails mid-study for a specific subgroup.
- Assuming Production-status settings are still editable. Once even one record has been randomized in Production, the corresponding configuration is locked; there is no in-place edit, only a full reset.
- Granting Randomization user rights by habit rather than by design. On a blinded study, review who actually holds this permission — it should match the study’s blinding plan exactly, not the coordinator team’s general project access.
Frequently asked questions
Does REDCap generate the randomization sequence for me?
No. REDCap stores and dispenses a pre-built allocation table but does not generate the random sequence itself — that has to be produced outside REDCap (commonly in R, SAS, Stata, or a spreadsheet) and uploaded as a CSV before the module can be enabled.
Can I change the target field or stratification after my project is live?
Not through the normal Setup interface. Once a project is in Production status, and especially once any record has been randomized, the Randomization Setup page locks. Changing the configuration at that point requires a full module reset — deleting and rebuilding the allocation table — which should be backed up and treated as a rare, deliberate action, not a routine edit.
How does REDCap handle multi-site randomization?
By stratifying on Data Access Group (DAG) instead of, or in addition to, a project field — each site gets randomized independently against its own portion of the allocation table rather than pooling assignment across every site in the project.
Who can see a participant’s assigned group?
Only users explicitly granted the “Randomization” permission under User Rights — a separate right from ordinary data-entry access, which is what keeps a blinded study blinded even for coordinators who otherwise have full access to the project.
For the broader survey and data-collection platform landscape this module sits inside, see the Research Tools hub, or compare REDCap directly against a non-clinical survey platform in Qualtrics vs REDCap for Academic & Clinical Research. For the underlying study-design concepts, see Randomization Methods in Clinical Trials, Randomized Controlled Trial (RCT), Blinding and Masking in Clinical Trials, and Stratified Sampling. For the rest of REDCap’s project-setup mechanics, see what REDCap is, the REDCap Data Dictionary, and REDCap branching logic.
