REDCap: Roles & Permissions

This article provides a quick reference table for the roles and corresponding permissions available in REDCap projects. It is designed to help REDCap users and study teams understand the level of access associated with each role and assign responsibilities appropriately.

This article provides a quick reference for the roles and corresponding permissions available in REDCap projects. It is designed to help REDCap users and study teams understand the level of access associated with each role and assign responsibilities appropriately.

 

Updated Role Structure

The REDCap@UNC team has streamlined role management to give study teams more flexibility. Under the updated model, Project Manager (PM) holds full administrative access to a REDCap project. Previously separate roles, including Principal Investigator (PI), Project Lead (PL), and Data Manager (DM), will now be consolidated under Project Manager going forward.

The standardized roles are:

• Project Manager (PM) — full administrative access
• Study Coordinator (SC)
• Data Entry (DE)
• Biostatistician (BioStat)
• Data Monitor (DMon)

These roles are intended to serve as guidelines rather than strict requirements. Study teams are no longer required to adhere exactly to these predefined roles — teams may create custom roles and modify role permissions as needed to fit their project's workflow.

Best practice: It is recommended that permissions be assigned and limited based on each user's actual usage and responsibilities within the REDCap project, minimizing access to only what is necessary for their role.

 

Managing users

The study team is responsible for: 

• Assigning users to appropriate roles
• Expiring user access when it is no longer needed (rather than deleting users from the project)

 

When to use a custom role vs. a standard role

To avoid the permission inconsistencies the previous policy aimed to prevent, study teams should default to the standard roles above whenever a team member's responsibilities reasonably fit one of them. Consider creating a custom role only when:

• A user's responsibilities span multiple standard roles in a way that would otherwise require over-granting access (e.g., someone who only needs data export rights, not full DE or SC access)
• A standard role grants broader access than the person actually needs for their specific task
• The project has a workflow or team structure that doesn't map cleanly onto the standard roles (e.g., a limited-term consultant, an external auditor, or a role specific to a multi-site study)

The project uses a workflow that requires multiple users with the same function but separate role assignments — for example, projects using Double Data Entry may need two distinct Data Entry roles (e.g., Data Entry #1 and Data Entry #2) so that each entry can be tracked and compared independently

When creating a custom role, apply the same principle of least privilege used for standard roles: grant only the permissions the user needs to perform their actual function, and document the rationale for the custom role so future team members understand why it exists.