Amplitude User Management Guide

• Model type: hybrid
• Description: Amplitude uses a layered permission model. By default, permissions exist at the organization level, giving users the same access across all projects. Growth and Enterprise customers can enable project-level permissions, allowing different roles per project. Enterprise customers additionally get full RBAC with custom roles (Roles > Permissions > Actions hierarchy) and permission groups for bulk assignment. When a user belongs to multiple groups or has both individual and group permissions, Amplitude grants the union (highest level) of all assigned permissions.
• Custom roles: Yes
• Custom roles plan: Enterprise
• Granularity: Organization-level by default; project-level available on Growth and Enterprise (must be enabled by CSM); flag/experiment-level available on Enterprise. RBAC custom roles are scoped by product area (Analytics, Experiment, etc.) with Base, Expanded, or Full permission tiers per area.

1. Navigate to Settings (gear icon) > Organization settings > Members & Groups.
2. From the Members page, click 'Invite New Users'.
3. Type one or more email addresses into the text box; press Enter after each address.
4. For each email, select the appropriate team.
5. Click Next.
6. (Enterprise with Groups enabled) Select the group(s) this user belongs to from the 'Select Groups' dropdown. The user inherits all group project permissions. Click Next.
7. Select the individual projects the user has access to and choose the appropriate role from the dropdown for each project. Click Next.
8. Specify the user's default project and select appropriate team spaces. Click Next.
9. Review the invitation and click Send.

Required fields: Email address (unique identifier; cannot be changed after account creation), Team assignment, Project access and role (at least one project recommended)

Watch out for:

• Only Admins and Managers can add users to the organization; Members can only invite to team spaces.
• New users are assigned the Viewer role by default.
• Email addresses are permanent unique identifiers; neither users nor admins can change them. Changing email requires inviting a new address, transferring content, and removing the old address.
• Project-level permissions must be enabled by contacting the Customer Success Manager; it is not on by default.
• If a user is assigned to a group during invite, their group-granted permissions cannot be downgraded at the individual level.
• An optional 'Allow Team Members to Request Access' toggle (Settings > Advanced Settings) lets users request access from the login page, requiring admin approval.

• Can delete users: No
• Delete/deactivate behavior: Amplitude does not have a 'deactivate' state for organization members. The only removal action is 'Remove', which immediately eliminates all access provisions and removes the user from the organization. There is no soft-disable or suspension. Full account/profile deletion from Amplitude's system requires a GDPR request to privacy@amplitude.com. Via SCIM (Okta), removing a user assignment from the Okta application removes the user from the Amplitude organization.

1. Navigate to Settings > Organization settings > Members & Groups.
2. Check the box next to the name of the user(s) to remove. Multiple users can be selected at once.
3. Click Remove.
4. In the 'Remove Members?' modal, optionally check the box to transfer the removed user's content to another existing user before confirming.
5. Confirm removal.

Watch out for:

• Content transfer can only occur before the user is deleted; the bulk transfer process cannot be reversed.
• The sole Admin of an organization cannot be removed until another user is promoted to Admin.
• User spaces (personal spaces) and their content are not migrated during domain changes or transfers; only cohorts, charts, dashboards, and notebooks are transferable.
• SCIM removal (via Okta unassignment) removes the user from the Amplitude organization but does not delete their Amplitude account or data from Amplitude's system.
• Full GDPR/profile deletion from Amplitude's system requires contacting privacy@amplitude.com separately.

• Where to check usage: Settings (gear icon) > Organization settings > General > Plans & Billing section. Displays contract start/end date, MTU/event limit, MTUs/events used this month and last month.
• How to identify unused seats: Amplitude does not expose a native 'last login' or 'inactive user' report in the admin UI per official docs. The Members & Groups page shows Joined Users vs. Pending Users (outstanding invites). Pending users who have never accepted can be identified and removed. No documented automated idle-user detection for internal seats.
• Billing notes: Amplitude pricing is usage-based (MTUs and event volume), not per-internal-user seat. Growth and Enterprise plans require annual contracts with custom pricing negotiated with sales. Plus plan billing is self-serve and manageable from Settings > Plans & Billing. Overages for exceeding MTU/event limits can incur additional charges. Negotiation is common on Growth/Enterprise renewals (discounts of 8–25% reported). Startup Scholarship provides one year of Growth plan features free for qualifying startups.

Without automated provisioning, every app in your stack demands the same repetitive admin work: navigate to Members & Groups, click Invite New Users, enter each email, assign a team, select projects, set a role per project, and confirm.

For Amplitude specifically, that multi-step invite flow is compounded by the fact that project-level permissions are off by default and require a CSM to enable - meaning misconfigured access is easy to miss at scale.

Offboarding carries its own risk: Amplitude has no deactivate or suspend state, so removal is immediate and permanent from the org. Content orphaning is a real operational cost - ownership transfer must happen before removal, and the window to do so closes the moment you confirm.

Email addresses are immutable identifiers; a name change or domain migration requires inviting a new address, manually transferring all charts, dashboards, cohorts, and notebooks, then removing the old account.

Practitioners flag three recurring friction points with Amplitude's user management. First, the interaction between group-assigned and individually-assigned permissions is non-obvious: when a user belongs to multiple groups, Amplitude silently grants the union (highest level) of all permissions, which can result in broader access than intended.

Second, project-level permissions require CSM engagement to activate and are not surfaced as a self-serve toggle, creating a support dependency for a foundational access control feature.

Third, there is no native inactive-user report in the admin UI - the Members & Groups page distinguishes only Joined from Pending users, leaving admins without a reliable signal for identifying stale seats.

Community reviewers also note that pricing complexity and permission model depth create a steeper learning curve for non-technical admins managing the platform.

Common complaints:

• SCIM availability depends on organization enablement by Amplitude; must contact sales or CSM to activate.
• Key regeneration for SCIM immediately invalidates the old key, which can disrupt existing IDP integrations.
• Project-level permissions are not enabled by default on Growth/Enterprise; requires CSM engagement to turn on.
• Email addresses cannot be changed after account creation; changing a user's email requires a multi-step manual process (invite new, transfer content, remove old).
• User permissions model is complex and confusing for non-technical admins, particularly the interaction between group-assigned and individually-assigned permissions.
• No native 'deactivate' or 'suspend' state; removal is immediate and permanent from the org.
• Content transfer must be completed before user removal is confirmed; the process cannot be reversed.
• Pricing opacity for Growth and Enterprise plans makes cost forecasting difficult; costs can escalate quickly with MTU growth.
• Some important admin features (RBAC custom roles, project-level Experiment permissions) are gated behind Enterprise plan.
• Documentation has been reported as occasionally misleading by developers.

Manual management is workable for small, stable teams where Amplitude is a secondary tool and org membership changes infrequently.

The calculus shifts when you account for every app in your portfolio that requires the same invite-assign-remove cycle: the cumulative overhead of multi-step provisioning, CSM-gated permission features, and an immediate-removal-only offboarding model adds up quickly across a mid-size IT environment.

The absence of a deactivate state and the immutability of email addresses are the two constraints most likely to create audit or compliance exposure at scale. If your organization is already on Growth or Enterprise and has SSO in place, the incremental cost of enabling SCIM is low relative to the manual overhead it eliminates.

Bottom line

Amplitude's manual user management is functional but layered: a multi-step invite flow, project-level permissions that require CSM activation, no native idle-user detection, and an immediate-removal-only offboarding model that puts the burden of content transfer squarely on the admin.

For teams with low churn and a small analyst headcount, the manual process is manageable.

For organizations running Amplitude at scale - multiple projects, frequent onboarding and offboarding, or strict access review requirements - the operational cost of manual administration accumulates quickly, and the risk of orphaned content or over-permissioned users through group inheritance is real.