Update Amplitude Roles for the collaborator | OpsBlu Docs

Update Amplitude Roles for the collaborator

How to modify user roles, permissions, and access levels in Amplitude. Covers role changes, app access management, API key rotation, and common access.

Update Access & Roles

Use this guide when Amplitude roles or project permissions need to change. Updating access allows you to adjust permissions without removing and re-adding users, which preserves their activity history, audit trails, and owned assets.

Role and permission changes take effect immediately in Amplitude. Users don't need to log out - permissions update on their next page load or action.

When to Update Access

Update user access when:

  • A role changes: Data Analyst promoted to Team Lead; Manager moving to individual contributor
  • Project scope expands or contracts: New products launch; agency wins/loses client; team member takes on additional products
  • Module access changes: Organization purchases Govern, Experiment, or Accounts modules that require new permissions
  • Temporary elevation: User needs Admin for one-time task (tracking plan deployment, integration setup)
  • Security or compliance requirement: Audit reveals user has more access than needed; principle of least privilege enforcement
  • Organizational restructure: Team mergers, department changes, or reporting line shifts
  • SSO/SCIM group mapping changes: Identity provider group updates require Amplitude role adjustments

Pre-Update Assessment

Before making changes, assess:

Clarify the change request

  • Role change or project scope change? Determine if adjusting organization role, project list, or both
  • Permanent or temporary? Document planned revert date if temporary elevation
  • Which projects? List specific projects to add or remove
  • Module permissions needed? Identify if Govern, Experiment, or Accounts access is required
  • Reason for change: Business justification, security requirement, or organizational change

Review current state

  1. Go to Settings → Members & Groups and open user's account
  2. Note current:
    • Organization role (Admin, Member, No Access)
    • Project assignments and roles (Admin, Manager, Membe, Viewer)
    • Add-on module permissions (Govern, Experiment, Accounts)
    • Last login date
  3. Screenshot for "before" record
  4. Document which assets they currently own (dashboards, notebooks, metrics, cohorts)

Identify impact of changes

If reducing permissions (downgrading role, removing projects):

  • Check if user owns dashboards, notebooks, metrics, cohorts, tracking plans in projects being removed
  • Transfer critical assets before downgrading if necessary
  • Ensure another Admin exists for projects losing Admin access
  • Verify downstream dependencies (integrations, scheduled reports, data pipelines)

If expanding permissions (upgrading role, adding projects):

  • Confirm business justification and approval
  • Verify user needs the elevated access for their job function
  • Document expected scope and duration
  • Set calendar reminder if temporary

Obtain approval

For role elevations, project additions, or module access grants:

  • User's manager or department head
  • Data governance lead if adding Govern access
  • Security or compliance if adding Admin or organization-level rights
  • Product owner if adding access to specific product projects
  • Save approval for compliance audit trail

Change Execution

Step 1: Access user management

  1. Sign in as Admin or Organization Owner
  2. Go to Settings → Members & Groups
  3. Locate the user by name or email
  4. Click on their name to open the user profile

Step 2: Adjust organization role (if needed)

If organizational responsibilities changed:

  1. In Organization Role section, select new role:
    • Admin: Full organization control (billing, SSO, integrations, all projects)
    • Member: Standard user with project-level permissions only
    • No Access: Organization-level access revoked (retains only explicit project permissions)
  2. Consider impact:
    • Upgrading to Admin: User gains access to billing, SSO configuration, user management, all projects, and organization settings
    • Downgrading from Admin: Loses organization-level privileges; retains only explicit project permissions
    • Setting to No Access: Requires explicit project permissions to access any data
  3. Save changes

Best practice: Use Organization Admin sparingly. Most users should be Members with project-level permissions.

Step 3: Modify project access (if needed)

If project scope changed:

  1. In Projects section, review current project list
  2. Adding projects:
    • Click + Add Project or check boxes for new projects
    • Select appropriate role for each project:
      • Admin: Full project control (settings, tracking plan, integrations)
      • Manager: Can create cohorts, dashboards, and manage team reports
      • Member: Can create personal dashboards and analyses
      • Viewer: Read-only access to shared content
  3. Removing projects:
    • Uncheck boxes for projects to remove
    • Or set project role to No Access
  4. Changing project roles:
    • Update dropdown for each project individually
  5. Save changes

Best practice: Avoid "All Projects" access unless truly needed. Explicit project grants provide better auditability.

Step 4: Adjust module permissions (if needed)

If add-on module access changed:

  1. In Add-On Permissions or module-specific sections:
    • Govern: Tracking plan editor, data quality rules
    • Experiment: A/B test creation and analysis
    • Accounts: Account-level analytics and journeys
  2. Enable or disable module access per project as needed
  3. For Govern specifically:
    • Tracking Plan Editor: Can approve/block events
    • Tracking Plan Viewer: Can view but not edit plans
  4. Save changes

Step 5: Save and verify

  1. Click Save or Update User
  2. Refresh and verify:
    • Organization role updated correctly
    • Project list shows correct additions/removals
    • Project roles reflect changes
    • Module permissions are accurate
  3. Screenshot for "after" record
  4. Check Access Log to confirm change was recorded

Step 6: Notify the user

Send email or Slack message to user explaining:

  • What changed: New role, updated project list, module permissions added/removed
  • Why: Business justification or organizational change
  • When effective: Immediate or future date
  • What they can now do: New capabilities or restrictions
  • Duration: If temporary, when access will be reverted
  • Contact: Who to ask if questions or issues

Post-Update Validation

User confirmation

  • Ask user to log in and confirm expected project access
  • Verify they can see new projects or cannot access removed projects
  • If upgraded to Admin, verify can access organization settings
  • If downgraded, verify cannot access previous Admin features

Asset review

If project scope reduced:

  • Confirm dashboards/notebooks under removed projects were transferred or are no longer needed
  • Verify user can't edit assets in removed projects
  • Check that shared dashboards still work for other users

If upgraded to project Admin:

  • Verify can access project settings
  • Confirm can manage tracking plan (if Govern enabled)
  • Test integration management permissions

Functional testing

Test specific changes:

  • Govern access: Can user approve/block events in tracking plan?
  • Experiment access: Can user create/edit experiments?
  • Admin role: Can user access billing, SSO, or user management?
  • Viewer role: Verify user cannot create new content, only view shared

Documentation

  • Update access log with details:
    • User email and name
    • Date of change
    • Organization role: old → new
    • Projects: added/removed with roles
    • Modules: granted/revoked
    • Reason and approver
    • Temporary or permanent
  • Update team roster or org chart
  • Add note to ticketing system
  • Update RACI matrix if responsibilities changed

Monitoring

  • Set follow-up reminder for 1-2 weeks to verify change working as expected
  • If temporary elevation, set calendar alert to revert on planned date
  • Include in next quarterly access review to verify still appropriate
  • Monitor audit logs for any unusual activity after permission increase

Bulk Update Operations

For updating multiple users at once:

Via SCIM/SSO

If using automated provisioning:

  1. Update user attributes in identity provider (Okta, Azure AD, etc.)
  2. Verify SCIM sync completes within expected timeframe
  3. Check Amplitude for updated roles and permissions
  4. Document which IdP groups map to which Amplitude roles/projects

Via API

For programmatic updates:

  1. Use Amplitude's Organization Management API
  2. Authenticate with organization API key
  3. Call appropriate endpoints for role/project updates
  4. Verify responses and handle errors
  5. Log all API operations for audit trail

Manual bulk updates

If multiple users need the same change:

  1. Document all users requiring the update
  2. Process each user individually (Amplitude doesn't have native bulk UI)
  3. Use consistent approach for each
  4. Screenshot each before/after
  5. Document all changes in single access review ticket

Troubleshooting

User can't see new projects:

  • Verify projects were saved correctly
  • Have user log out completely and back in
  • Check if SSO/SCIM is overriding manual changes
  • Confirm projects are active and not archived

User still has old role permissions:

  • Confirm save completed successfully
  • Have user clear cache and reload Amplitude
  • Check if SSO attributes are reverting the change
  • Contact Amplitude support if persists

User lost access to dashboards they created:

  • If projects were removed, dashboards in those projects become inaccessible
  • Re-add project temporarily to export dashboards
  • Or have another Admin with access export/transfer them

Upgraded to Admin but can't access billing:

  • Organization role may not be set to Admin
  • Verify "Organization Admin" not just project Admin
  • Some billing features may be Owner-only
  • Contact Amplitude support

Module permissions not working:

  • Verify organization has purchased the module
  • Confirm module is enabled for the specific project
  • Check if user needs both organization AND project-level module permission
  • Have user log out and back in

SCIM keeps reverting manual changes:

  • SCIM provisioning will override manual role changes
  • Make changes in identity provider instead
  • Document SCIM role mapping for team reference
  • Or temporarily disable SCIM sync for manual override (not recommended)

Best Practices

  • Document every change with reason, approver, and date
  • Screenshot before and after for compliance audit trails
  • Notify users immediately after access changes
  • Set revert reminders for temporary elevations
  • Use least privilege: Grant minimum access needed for job function
  • Review quarterly: Verify all users still need current access levels
  • Prefer SCIM/SSO: Automate provisioning when possible
  • Test after changes: Verify user has expected permissions
  • Coordinate with security: Align role changes with security policies
  • Maintain separation of duties: Avoid granting excessive Admin access

Common Use Cases

Promoting Data Analyst to Team Lead

  1. Obtain approval from department head
  2. Review current projects and identify gaps
  3. Upgrade organization role from Member to Admin (if needed for team management)
  4. Add projects they'll now manage
  5. Grant Govern access if they'll approve tracking plans
  6. Set project role to Admin for teams they'll lead
  7. Document promotion with effective date
  8. Notify user of new responsibilities and access

Downgrading departing Admin (pre-offboarding)

  1. Confirm departure timeline with HR
  2. Identify assets owned (dashboards, metrics, cohorts, tracking plans)
  3. Transfer ownership to replacement or manager
  4. Downgrade organization role from Admin to Member
  5. Reduce project roles to Viewer for final weeks (read-only access)
  6. Keep access active until official last day
  7. Document downgrade and planned full removal date

Temporarily elevating for integration setup

  1. Obtain approval with specific task and revert date
  2. Current state screenshot
  3. Upgrade to project Admin for relevant project only
  4. Grant necessary module permissions (e.g., enable integrations)
  5. Notify user to complete task by specified date
  6. Set calendar reminder to revert on completion date
  7. After task complete, downgrade back to previous role
  8. Document temporary elevation in audit log

Expanding scope (agency wins new client)

  1. Confirm new client covered by contract/SOW
  2. Obtain approval from account owner or procurement
  3. Add new project(s) to user's access list
  4. Set appropriate role (usually Manager or Member)
  5. Verify user can access new projects
  6. Document with contract or SOW reference
  7. Notify agency of expanded access
  8. Update vendor access documentation

Reducing scope (project sunset)

  1. Confirm project is being deprecated or sunset
  2. Identify all users with access to the project
  3. Transfer any critical dashboards or metrics to other projects
  4. Remove project from user's access list
  5. Verify user no longer sees project in Amplitude
  6. Document project sunset and access removal
  7. Update team documentation
  8. Consider archiving project if supported

Moving user between teams/departments

  1. Confirm organizational change with HR or manager
  2. Review current project access and determine new needs
  3. Add projects for new team/department
  4. Remove projects from old team/department (unless overlap needed)
  5. Adjust roles to match new responsibilities
  6. Update organization role if team lead responsibilities change
  7. Transfer ownership of assets if applicable
  8. Document organizational change
  9. Notify both old and new managers
  10. Update team roster and org chart

Granting Govern access for tracking plan ownership

  1. Confirm user will manage tracking plan quality
  2. Obtain approval from data governance lead
  3. Enable Govern module access for relevant projects
  4. Set to Tracking Plan Editor if they'll approve/block events
  5. Set to Tracking Plan Viewer if read-only needed
  6. Train user on tracking plan workflows if first time
  7. Document grant with governance approval reference
  8. Notify data engineering team of new tracking plan owner

Seasonal contractor access adjustment

  1. Contractor returning for seasonal work (e.g., holiday analytics)
  2. Review previous access and projects
  3. Re-enable projects for current season
  4. Set appropriate time-limited role (usually Viewer or Member)
  5. Document contract start and end dates
  6. Set calendar reminders for access removal at contract end
  7. Notify contractor of access grant
  8. Track in vendor management system

Compliance-driven access reduction

  1. Security audit identifies excessive permissions
  2. Document current access levels
  3. Work with user's manager to determine minimum required access
  4. Remove unnecessary projects
  5. Downgrade roles where Admin not needed
  6. Revoke unused module permissions
  7. Screenshot before and after states
  8. Document compliance requirement driving change
  9. Report changes to security/compliance team
  10. Schedule follow-up review in 90 days
Back to top