RBAC Best Practices

Amplitude’s Role-based Access Controls (RBAC) system unifies permissions across all Amplitude products and features. This guide describes best practices for designing and governing access at the project level, and not separately for each project.

Projects in Amplitude

In Amplitude, projects define the data users can view or modify, the Amplitude products and features they can use, and the actions they can perform within that project.

When you configure and manage permissions by project, users in your organization receive consistent access across all Amplitude products within that project.

System architecture

Follow these guidelines to help ensure your RBAC implementation meets your organization’s access and security requirements.

Use Groups as the default management layer

Groups are the foundation for managing access at scale. In Amplitude, a group defines:

• The projects that the group’s members have access to
• The roles users hold in those projects
• Any Data Access Controls that apply

All members of a group inherit the same set of permissions for the same projects. This helps simplify onboarding, offboarding, and audits.

Use direct role assignment only when necessary

Use individual user-level permissions only when group membership isn’t practical. For example:

• Contractors or temporary collaborators
• Executives who need read-only access
• Service or system accounts

If you assign permissions directly to a user, document the reason internally.

Standardize roles across the organization

Define a small set of core, reusable roles that apply across projects and products. This creates a shared mental model, and reduces administrative overhead. Review the following table for examples of roles you might create, their intended use, and the permissions they provide.

Design groups

Groups are the foundation of scalable access in Amplitude’s RBAC system. Amplitude recommends building groups that combine function and scope into one logical structure by considering:

• The way in which users in your organization use Amplitude
• The projects those users need to access

Anchor groups to both workflow and project scope

As you plan your groups, make sure to design groups that capture:

• How teams in your organization use Amplitude.
• The projects each team should access.

In other words, consider both the team’s function or use case, and the data or product context they need to do their job.

Ensure each group describes what the members of the group do, and where they do it.

Keep groups project-scoped and purposeful

A well designed group is one that provides a clear function, a set of projects, and a consistent role.

To achieve this:

• Assign each group to the specific projects they need. Avoid granting access to the entire workspace.
• If a team works across projects, assign those within the same group.
• Avoid overlapping or nesting groups to keep access clear and auditable.

Apply clear and consistent naming

Use a predictable, readable naming format that reflects the role and the project scope:

Function / Use Case - Role - Projects

The following table contains a list of group names using this format.

Consistent naming makes it clear who belongs in the group, and the content and features they can access.

Keep membership manageable

Think of groups as access blueprints. Each one should have a clear purpose, ownership, and lifecycle management.

• Try to keep your groups to between 10 and 50 members.
• Split groups when their project roles or responsibilities diverge. For example, Experimentation – Engineer – Android App or Experimentation – Engineer – iOS App.
• Avoid catchall groups like All Analysts or Marketing Team. They can create confusion, and overexpose parts of your Amplitude environment.