REDCap User Rights and Data Access Groups (DAGs)

REDCap controls who can see and do what in a project through two separate, layered mechanisms: User Rights, which set what a given user can do on the forms and fields they can already reach, and Data Access Groups (DAGs), which restrict which records a user can reach in the first place. Confusing the two — or setting one without checking the other — is the single most common access-control mistake in multi-site REDCap projects, and it produces the same failure every time: a user who was only supposed to see one site’s participants can see everyone’s.

This guide covers what each User Rights setting actually controls, what a DAG does mechanically, and the specific setup mistakes that let a site-level user see or export data outside their assigned site. For the underlying research-informatics platform itself, see the REDCap dictionary entry; for the project’s field-level specification, see REDCap Data Dictionary: Structure, Editing, and Moving a Project.

Why this matters for multi-site studies

A single-site study can often get away with a flat permission model: every coordinator sees every record, and User Rights alone are enough to differentiate a data-entry role from a PI role. A multi-site or role-differentiated study cannot. When Site A’s coordinator opens the project, REDCap’s record list, reports, and exports must show only Site A’s participants — not because Site A’s coordinator lacks the technical skill to keep the data separate, but because the study’s IRB approval, data use agreements, and often law (HIPAA minimum-necessary, GDPR data minimization) require it. User Rights cannot do this on their own: rights are granted per user, not scoped to a subset of records. That scoping is what DAGs exist for.

What User Rights actually control

REDCap’s User Rights page (Project Setup → User Rights, or the standalone “User Rights” module) is a per-user permission matrix set independently for every project. Rights fall into a few functional groups:

Form-level and instrument-level access

For each data-collection instrument in the project, a user can be granted No Access, Read Only, or View & Edit. This is set form-by-form, not project-wide — a user can have edit access to an intake form and read-only access to an adverse-event form in the same project. Users with no rights to a given form never see it in the record navigation, in reports built from it, or in exports (subject to export rights, below).

Field-level (“Field Embargo”) permissions

Beneath form-level rights, individual fields can be marked so that specific user roles cannot view or edit them even when they have edit rights to the rest of that form — used for fields that only a subset of the study team should see (a randomization code held back from blinded coordinators, a free-text field containing information beyond a data-entry role’s scope). This is a narrower, per-field override layered on top of the coarser form-level setting, not a replacement for it.

Record-level actions: create, delete, rename

Separate checkboxes control whether a user can create new records, delete existing records, and rename records. These are project-wide (they are not set per form), and are commonly restricted to a small subset of the study team — most coordinators need to create and edit records but should not be able to delete them, since a deletion in REDCap removes all of that record’s data across every instrument and every event.

Export rights

Export rights are set at three levels, independently of form-level view/edit access: No Access, De-Identified (excludes fields tagged as identifiers, plus free-text and date fields unless explicitly included), and Full Data Set. A user can have full view/edit access to a form on-screen but only de-identified or no export rights — a deliberate split for study teams where day-to-day data entry is broader than the group cleared to pull raw exports. Export rights govern the Data Export Tool, the API’s export methods, and PDF/CSV downloads generally.

Other User Rights that matter for multi-site studies

• Data Access Groups — whether the user can assign records and other users to DAGs (a project-administration right, distinct from simply belonging to a DAG oneself; see below).
• Reports — whether a user can create/edit custom reports, versus only running reports someone else built.
• User Rights itself — whether the user can grant or modify other users’ rights. This is effectively an administrative-access right and should be held by very few people on a multi-site project.
• Data Quality, Randomization (the permission that governs whether a user can view a participant’s assigned arm — see REDCap Randomization Module), and several other module-specific rights follow the same pattern: a checkbox independent of form-level access.

What a Data Access Group does

A Data Access Group is REDCap’s mechanism for partitioning a single project’s records by site (or by any other grouping a study needs — site is the overwhelmingly common case, but a DAG can represent any subdivision the study wants to enforce). Mechanically:

• An administrator defines one DAG per site under Project Setup → User Rights → Data Access Groups.
• Every record gets assigned to exactly one DAG, either automatically (when a DAG-restricted user creates the record, it is stamped with that user’s DAG) or manually by an administrator.
• Every user can be assigned to at most one DAG. A user with no DAG assignment is unrestricted and sees every record in the project, subject only to their form-level and export rights.
• A user assigned to a DAG sees only records belonging to that DAG — in the record list, in reports, on the Data Export Tool, and through the API. This restriction is enforced independently of, and in addition to, form-level and export rights: a DAG-restricted user with Full Data Set export rights does not get every site’s data, they get the full data set for their own site’s records only.

This is the standard, and effectively the only built-in, mechanism REDCap offers for a multi-site study where each site’s coordinators should see only their own site’s participants. Because it operates at the record level rather than the field or form level, DAGs and User Rights answer two different questions — “which records can this user reach” versus “what can this user do once they reach a record” — and a project generally needs both configured correctly, not one in place of the other.

The DAG Switcher right

A separate right, DAG Switcher, lets a user who does not have a DAG restriction of their own temporarily view the project as though they belonged to a specific DAG, switching between sites via a dropdown, without a permanent per-user DAG assignment. It exists for coordinating-center staff, study monitors, or data managers who legitimately need to move between sites’ views — but because it is granted as an unrestricted “can view any site on demand” right rather than a fixed single-site assignment, it functionally removes the record-level restriction DAGs are supposed to provide for whoever holds it.

Common setup mistakes

Export rights granted without a matching DAG restriction

The most consequential and most common error: a user is given Full Data Set (or even De-Identified) export rights as part of a role template, but is never assigned to a DAG. Because DAG membership and export rights are configured on two different parts of the same User Rights page, it is easy to correctly restrict a user’s editable forms while forgetting that, with no DAG assigned, that same user’s export pulls every site’s records in one file. This is especially easy to miss when new users are added by cloning an existing user’s rights profile — cloning copies form and export rights but does not necessarily carry the DAG assignment with it in every version/workflow, so a cloned “coordinator” role can silently end up DAG-unrestricted.

DAG Switcher granted too broadly

Because DAG Switcher is convenient for anyone who occasionally needs a cross-site view, it tends to get handed out generously — to every research assistant “just in case,” rather than reserved for the handful of coordinating-center or monitoring roles that actually need it. Every person holding DAG Switcher is, in effect, DAG-unrestricted: they can view any site’s records on demand. A study with DAG Switcher on ten user accounts has ten users who can see cross-site data, whatever their form-level rights say.

Records created before a user’s DAG assignment

If a user creates records before being assigned to a DAG (or while temporarily unassigned during an account transition), those records are not retroactively stamped with a DAG — they stay unassigned, visible to every unrestricted user and invisible in the way a properly-scoped record would be. Periodically auditing for DAG-unassigned records is a reasonable check on a live multi-site project, not just a one-time setup step.

Assuming form-level “No Access” replaces a DAG restriction

Setting a form to No Access keeps a user from opening that instrument, but it does nothing about which records they can browse, report on, or export from the forms they do have access to. Teams sometimes reach for form-level restriction to solve a record-visibility problem it was never designed to solve, leaving DAGs unconfigured because the form-level lockdown “looks” restrictive enough on the surface.

One administrator, no second reviewer

Because both User Rights and DAG assignment sit on the same project-administration page, a single misclick (assigning the wrong DAG, cloning the wrong template, forgetting to save a DAG change before moving to the next user) is easy to make and easy to miss without a second person reviewing the access matrix before a multi-site project goes live — particularly for federally funded or IRB-governed studies where a data-access breach is a reportable event.

Setting it up correctly, in order

1. Build and finalize the project’s form-level and field-level User Rights roles first (e.g. “Coordinator,” “PI,” “Monitor,” “Data Manager”) as reusable templates, independent of any site.
2. Create one DAG per site under Data Access Groups.
3. Assign every site-based user to exactly one DAG, and confirm export rights on that account match what the role template intends — do not assume a cloned account inherited the DAG assignment.
4. Reserve DAG Switcher for the smallest set of coordinating-center/monitoring accounts that genuinely need cross-site visibility, and treat every account holding it as fully unrestricted for access-review purposes.
5. Periodically re-export the User Rights matrix (REDCap can export it as a report) and check for accounts with export rights but no DAG, and for how many accounts hold DAG Switcher or the User Rights administrative right.

Related REDCap mechanics

DAGs and User Rights are project-configuration concerns separate from how data flows out of the project once access is correctly scoped — see The REDCap API: Tokens, Exports, and Automating Data Pulls for how the same export-rights restrictions apply to API pulls, and REDCap Branching Logic for the field-conditional logic that determines what a user sees once they have access to a form. For the regulatory backdrop that usually makes DAG configuration a compliance requirement rather than a convenience, see Is REDCap HIPAA Compliant? and the IRB dictionary entry. For eConsent-specific access considerations in multi-site studies, see REDCap eConsent Framework.

Frequently asked questions

Can a user belong to more than one Data Access Group?

No. A user can be assigned to at most one DAG in a given project. If someone genuinely needs to work across two sites, the options are DAG Switcher (see above, with its broader access trade-off) or two separate user accounts, each assigned to a different DAG — the second is more restrictive and more auditable, at the cost of managing two logins.

Do DAGs restrict what a user can do with a record, or only which records they see?

Only which records they see. Once a user can see a record (because it belongs to their DAG), their form-level, field-level, create/delete, and export rights determine what they can do with it, exactly as they would on a single-site project. DAGs and User Rights are independent axes that both have to be set correctly.

Does assigning a record to a DAG hide it from the study’s overall administrator?

No. A user with no DAG assignment of their own (the typical configuration for a project administrator or PI who oversees all sites) sees every record regardless of which DAG it belongs to. DAG restriction only applies to users who are themselves assigned to a DAG.

Can DAG assignment be changed after records already exist?

Yes, an administrator with the Data Access Groups right can reassign individual records to a different DAG at any time (for example, correcting a record entered under the wrong site). This is a manual, deliberate action, not something that happens automatically when a user’s own DAG assignment changes.

Is there a way to see which users have export rights without a DAG restriction?

REDCap does not surface this as a single flagged report, but the User Rights page can be exported (as a report/CSV) and reviewed for accounts that combine De-Identified or Full Data Set export rights with no DAG entry — the specific combination behind the most common real-world mistake described above.