Update Mixpanel Roles for the collaborator

Modify Mixpanel organization or project access for the collaborator as scopes change.

Adjust the collaborator' Mixpanel permissions whenever project coverage, security requirements, or responsibilities change. Mixpanel's dual-layer access model - organization-level roles and project-specific permissions - requires careful coordination to ensure the collaborator retains necessary access while maintaining security boundaries.

When to Update Access

Expansion Scenarios

New Projects Launch

Additional mobile apps, web properties, or staging environments come online
Multi-brand clients add separate Mixpanel projects for each brand
Development or QA environments require instrumentation validation
Regional projects (EU vs. US data residency) need separate access controls

Elevated Responsibilities

Collaborator begins managing Lexicon definitions and event taxonomy
Data Pipeline integrations to Snowflake, BigQuery, or S3 require Admin rights
Cohort syncs to advertising platforms need configuration permissions
Custom properties and computed properties require write access
Governance workflows demand audit log review capabilities

Integration Management

Setting up or modifying connections to Braze, Iterable, or other CDPs
Configuring scheduled exports or webhook destinations
Managing service account credentials for API-based integrations
Establishing real-time connectors to reverse ETL tools

Compliance and Audit Requirements

Security audits require temporary elevated access for review
Data mapping exercises need visibility across all projects
Privacy impact assessments require understanding of data collection scope
Incident response scenarios demand immediate diagnostic access

Reduction Scenarios

Scope Narrowing

Implementation phase completes; ongoing work shifts to analysis only
Contract amendments reduce the number of projects in scope
Seasonal campaigns end and associated project access is no longer needed
Client brings capabilities in-house and reduces external dependencies

Security Posture Changes

Zero-trust initiatives require least-privilege access reviews
Data classification changes elevate certain projects to restricted status
Compliance frameworks (SOC 2, ISO 27001) mandate access minimization
Incident response reveals over-provisioned permissions

Role Transitions

Team member moves from implementation to reporting functions
Collaborator transitions from hands-on work to advisory capacity
Client hires internal analytics team and reduces consultant access
Project ownership transfers to different vendor or internal team

SSO/SCIM Synchronization

Identity provider group memberships change
Organizational restructuring affects IdP role mappings
Automated provisioning workflows update based on HR system changes
Group-based access policies are refined or reorganized

Understanding Mixpanel's Role Hierarchy

Organization-Level Roles

Organization Owner

Complete control over billing, subscription, and organization deletion
Can transfer ownership to another user
Manages organization-level SSO and SCIM configurations
Controls organization settings including data residency and retention policies
Recommendation: Restrict to client finance/IT leadership; collaborators rarely need this role

Organization Admin

Creates and deletes projects within the organization
Manages organization members and their roles
Configures SSO settings and identity provider integrations
Oversees cross-project settings and policies
Cannot modify billing or delete the organization
Typical collaborator use case: When managing Mixpanel governance for a client

Organization Member

No organization-level privileges
Access determined entirely by project-level roles
Cannot view other organization members unless granted project access
Cannot create new projects or modify organization settings
Default for most collaborators: Sufficient when work is scoped to specific projects

Project-Level Roles

Project Admin

Permissions:
✓ Full project settings access
✓ Create/modify/delete events, properties, and cohorts
✓ Manage Lexicon (event definitions, property descriptions)
✓ Configure Data Pipelines and integrations
✓ Set up Cohort Syncs to advertising platforms
✓ Manage project-level users and permissions
✓ Configure data governance rules and retention policies
✓ Create and manage service accounts
✓ Access and configure APIs
✓ Delete the project (organization admins only can prevent this)

Use Cases:
- Full implementation and instrumentation work
- Lexicon management and data governance
- Integration setup and maintenance
- Data pipeline configuration

Project Analyst

Permissions:
✓ Create and save reports, dashboards, and boards
✓ Create cohorts and funnels for analysis
✓ Build and share Insights, Flows, and Retention reports
✓ Export data to CSV
✓ Create alerts and scheduled reports
✗ Modify Lexicon or event definitions
✗ Configure integrations or data pipelines
✗ Manage project settings or other users
✗ Access API credentials or service accounts

Use Cases:
- Ongoing analytics and reporting work
- Campaign performance analysis
- Dashboard creation and maintenance
- Ad-hoc investigation and exploration

Project Viewer

Permissions:
✓ View existing reports and dashboards
✓ Filter and slice existing views
✓ Export visible data to CSV
✗ Create new reports or saved analyses
✗ Modify existing dashboards or boards
✗ Create cohorts or computed properties
✗ Access raw data or API

Use Cases:
- Executive stakeholder review
- Compliance-friendly read-only access
- Client teams who consume reports but don't create them
- Temporary audit or review access

Permissions Matrix

Capability	Project Viewer	Project Analyst	Project Admin	Org Admin
View reports & dashboards	✓	✓	✓	✓
Create reports	✗	✓	✓	✓
Edit Lexicon	✗	✗	✓	✓
Manage integrations	✗	✗	✓	✓
Configure Data Pipelines	✗	✗	✓	✓
Create cohorts	✗	✓	✓	✓
Export data	✓ (visible)	✓	✓	✓
Manage project users	✗	✗	✓	✓
Delete project	✗	✗	✗	✓
Create new projects	✗	✗	✗	✓
Manage organization SSO	✗	✗	✗	✓
Access API credentials	✗	✗	✓	✓

Step-by-Step Update Procedures

Update via Mixpanel UI

Step 1: Access Organization Settings

Log in to Mixpanel with an Organization Admin account
Click your profile icon in the top-right corner
Select Organization Settings from the dropdown
Navigate to the Members tab

Step 2: Locate the Collaborator

Use the search bar to find the collaborator by email or name
Review current organization role and project assignments
Note existing permissions for documentation purposes
Take a screenshot for your IAM change record

Step 3: Modify Organization Role (if needed)

Click on the collaborator's row to expand details
Find the Organization Role dropdown
Select the new role:
- Admin if the collaborator needs to manage projects or organization settings
- Member for standard access (most common)
A confirmation dialog appears - review the impact summary
Click Confirm to apply the change

Important: Organization role changes take effect immediately but don't automatically grant project access. You must explicitly assign project-level permissions in the next step.

Step 4: Update Project-Level Permissions

Within the same member details panel, scroll to Project Access
You'll see a list of all organization projects with the collaborator's current role
For each project requiring a change:
- Click the role dropdown next to the project name
- Select the new role: Admin, Analyst, Viewer, or No Access
Add new projects:
- Click + Add Project
- Select the project from the dropdown
- Choose the appropriate role
- Click Add
Remove project access:
- Click the X icon next to the project
- Confirm removal in the dialog

Step 5: Review Cross-Project Access

Ensure consistency across related projects:

Production Projects:
- MyApp-Web-Production → Analyst
- MyApp-iOS-Production → Analyst
- MyApp-Android-Production → Analyst

Staging Projects:
- MyApp-Web-Staging → Admin (for instrumentation testing)
- MyApp-iOS-Staging → Admin
- MyApp-Android-Staging → Admin

QA Projects:
- MyApp-QA → No Access (no longer in scope)

Step 6: Save and Notify

Click Save Changes at the bottom of the panel
Mixpanel displays a confirmation message
Copy the change summary for documentation
Send a notification to the collaborator:

Subject: Mixpanel Access Updated - [Organization Name]

Your Mixpanel permissions have been updated:

Organization Role: Member
Project Access:
- MyApp-Web-Production: Analyst
- MyApp-iOS-Production: Analyst
- MyApp-Web-Staging: Admin

Effective: Immediately

Changes were made to align with updated project scope. Please verify
access by logging in at https://mixpanel.com. Contact [name] with questions.

Update via SCIM Provisioning

For organizations using SCIM with Okta, Azure AD, or OneLogin:

Step 1: Review IdP Group Mappings

Log in to your identity provider
Navigate to the Mixpanel application configuration
Review Group Assignments or Group Claims
Identify which groups map to Mixpanel organization/project roles

Step 2: Modify Group Membership

Locate the user in your IdP directory
Update group memberships:
- Remove from groups that grant unwanted access
- Add to groups that provide required access
Save changes in the IdP

Step 3: Trigger Synchronization

Okta:

1. Go to Applications → Mixpanel
2. Click Provisioning tab
3. Click "Provision User" or wait for next sync cycle (typically 40 minutes)
4. Monitor Integration → Provisioning → Logs for success confirmation

Azure AD:

1. Go to Enterprise Applications → Mixpanel
2. Navigate to Provisioning → Provision on demand
3. Enter the user's email
4. Click "Provision"
5. Review the provisioning steps and confirm success

OneLogin:

1. Go to Applications → Mixpanel
2. Click Provisioning tab
3. Click "Sync Users" to trigger immediate sync
4. Check Activity → Provisioning Logs for confirmation

Step 4: Verify in Mixpanel

Wait 5-10 minutes for propagation
Log in to Mixpanel as an Organization Admin
Navigate to Organization Settings → Members
Confirm the collaborator's roles reflect the IdP changes
If discrepancies exist, check:
- IdP attribute mappings (email must match exactly)
- SCIM configuration errors in Mixpanel
- Group claim rules in the IdP

Step 5: Document the Change

Record the following in your IAM system:

IdP groups modified
Previous and new group memberships
Expected Mixpanel organization and project roles
Timestamp of IdP change and Mixpanel verification
Ticket or approval reference

Update via Mixpanel API

For programmatic access management or bulk updates:

Step 1: Obtain API Credentials

Log in as an Organization Admin
Navigate to Organization Settings → Service Accounts
Create a service account with Org Admin privileges or use existing credentials
Copy the Service Account Secret (treat as a password)

Step 2: Update Organization Role

# Update a user's organization role
curl -X POST \
  https://mixpanel.com/api/app/organizations/[ORG_ID]/members/[USER_ID] \
  -u [SERVICE_ACCOUNT_USERNAME]:[SERVICE_ACCOUNT_SECRET] \
  -H "Content-Type: application/json" \
  -d '{
    "role": "admin"
  }'

# Roles: "owner", "admin", "member"
# Response includes updated user object

Step 3: Update Project-Level Permissions

# Grant project access
curl -X POST \
  https://mixpanel.com/api/app/projects/[PROJECT_ID]/members \
  -u [SERVICE_ACCOUNT_USERNAME]:[SERVICE_ACCOUNT_SECRET] \
  -H "Content-Type: application/json" \
  -d '{
    "email": "collaborator@agency.com",
    "role": "analyst"
  }'

# Roles: "admin", "analyst", "viewer"

# Update existing project access
curl -X PUT \
  https://mixpanel.com/api/app/projects/[PROJECT_ID]/members/[USER_ID] \
  -u [SERVICE_ACCOUNT_USERNAME]:[SERVICE_ACCOUNT_SECRET] \
  -H "Content-Type: application/json" \
  -d '{
    "role": "viewer"
  }'

# Remove project access
curl -X DELETE \
  https://mixpanel.com/api/app/projects/[PROJECT_ID]/members/[USER_ID] \
  -u [SERVICE_ACCOUNT_USERNAME]:[SERVICE_ACCOUNT_SECRET]

Step 4: Bulk Updates with Python

import requests
from requests.auth import HTTPBasicAuth

MIXPANEL_SERVICE_ACCOUNT = "your-service-account"
MIXPANEL_SECRET = "your-secret"
ORG_ID = "12345"

auth = HTTPBasicAuth(MIXPANEL_SERVICE_ACCOUNT, MIXPANEL_SECRET)

# Define collaborator's new project access
new_access = {
    "collaborator@agency.com": [
        {"project_id": "2891234", "role": "analyst"},
        {"project_id": "2891235", "role": "analyst"},
        {"project_id": "2891236", "role": "admin"},  # Staging project
    ]
}

for email, projects in new_access.items():
    # First, get the user ID
    user_response = requests.get(
        f"https://mixpanel.com/api/app/organizations/{ORG_ID}/members",
        auth=auth
    )
    users = user_response.json()
    user_id = next(
        (u["id"] for u in users if u["email"] == email),
        None
    )

    if not user_id:
        print(f"User {email} not found")
        continue

    # Update each project
    for project in projects:
        response = requests.post(
            f"https://mixpanel.com/api/app/projects/{project['project_id']}/members",
            auth=auth,
            json={"email": email, "role": project["role"]}
        )

        if response.status_code == 200:
            print(f"✓ {email} → Project {project['project_id']}: {project['role']}")
        else:
            print(f"✗ Error updating {email} on project {project['project_id']}: {response.text}")

SSO and SCIM Considerations

Group-Based Access Control

Okta Configuration Example:

Mixpanel-Org-Admin Group:
  → Pushes organization_role = "admin" claim
  → Members automatically receive Org Admin privileges

Mixpanel-Project-WebApp-Analyst Group:
  → Pushes project_access claim with project_id and role
  → Members receive Analyst access to Web App project

Best Practice:
- Create separate groups for each project + role combination
- Use naming convention: Mixpanel-[Project]-[Role]
- Map client org structure (Marketing, Product, Engineering) to groups

Azure AD Configuration:

1. Create Security Groups:
   - Mixpanel-Production-Analysts
   - Mixpanel-Staging-Admins
   - Mixpanel-Reporting-Viewers

2. Configure Attribute Mapping:
   - User Principal Name → email
   - Security Groups → roles (with transformation rules)

3. Set up Provisioning Filters:
   - Only provision users in specific departments
   - Exclude service accounts or bots

Handling SCIM Conflicts

Scenario: Manual Change Overridden by SCIM

If you manually update a role in Mixpanel but the user belongs to an IdP group:

The next SCIM sync will revert your manual change
To make the change permanent:
- Modify the IdP group membership, OR
- Temporarily disable SCIM for that user (not recommended), OR
- Create an exception in your SCIM configuration

Scenario: User Removed from IdP Group

Expected Behavior:
- User is deprovisioned from Mixpanel within next sync cycle (typically 40 min)
- User's saved reports and dashboards remain intact
- Shared boards show "Former Member" instead of user name

Actual Behavior in Some Configurations:
- User may be suspended but not fully removed
- Verify your SCIM deprovisioning settings
- Some organizations configure "soft delete" vs. "hard delete"

Verifying SCIM Status:

# Check recent SCIM events
curl -X GET \
  https://mixpanel.com/api/app/organizations/[ORG_ID]/scim/logs \
  -u [SERVICE_ACCOUNT_USERNAME]:[SERVICE_ACCOUNT_SECRET] \
  | jq '.[] | select(.user_email == "collaborator@agency.com")'

# Look for events like:
# - USER_CREATED
# - USER_UPDATED
# - USER_ROLE_CHANGED
# - USER_DEPROVISIONED

Security Recommendations

Principle of Least Privilege

Before Granting Admin:

Ask these questions:

Does the collaborator need to modify Lexicon definitions?
Will they configure Data Pipelines or external integrations?
Do they manage service accounts or API credentials?
Are they responsible for data governance policies?

If all answers are "No," use Analyst or Viewer instead.

Time-Bound Elevated Access:

For temporary needs:

1. Grant Admin access for specific implementation sprint
2. Set calendar reminder for role review
3. Downgrade to Analyst after project milestone
4. Document justification: "Q4 2024 mobile app instrumentation"

Multi-Factor Authentication

Enforce MFA for All Users:

Navigate to Organization Settings → Security
Enable Require Multi-Factor Authentication
Existing users receive email prompting MFA enrollment
New users must enroll during first login
Supported methods: Authenticator app (TOTP), SMS, hardware keys (WebAuthn)

Verify Collaborator MFA Status:

Organization Settings → Members → [Collaborator Name]
Look for green "MFA Enabled" badge
If missing, prompt collaborator to enroll before granting elevated access

API Secret Rotation

When updating a collaborator to Admin role or adding Data Pipeline access:

Rotate Project Tokens:

# List current project tokens
curl -X GET \
  https://mixpanel.com/api/app/projects/[PROJECT_ID]/tokens \
  -u [SERVICE_ACCOUNT_USERNAME]:[SERVICE_ACCOUNT_SECRET]

# Response includes token IDs and creation dates
# Rotate tokens older than 90 days or after role changes

curl -X POST \
  https://mixpanel.com/api/app/projects/[PROJECT_ID]/tokens/rotate \
  -u [SERVICE_ACCOUNT_USERNAME]:[SERVICE_ACCOUNT_SECRET] \
  -d '{"token_id": "abc123"}'

# Update all tracking implementations with new token

Service Account Hygiene:

When granting Admin access:
1. Review existing service accounts created by the collaborator
2. Verify their purpose and usage
3. Rotate secrets for accounts that haven't been used in 30+ days
4. Document which service accounts map to which integrations

Audit Trail Review

Post-Update Verification:

Navigate to Organization Settings → Activity Log
Filter by:
- User: Collaborator's email
- Date Range: Last 7 days
- Event Type: "Member role changed"
Verify the change appears with correct timestamp and initiator
Export the log entry:

curl -X GET \
  "https://mixpanel.com/api/app/organizations/[ORG_ID]/audit_log?user_email=collaborator@agency.com&start_date=2024-01-01" \
  -u [SERVICE_ACCOUNT_USERNAME]:[SERVICE_ACCOUNT_SECRET] \
  > mixpanel_audit_$(date +%Y%m%d).json

Store the export with your IAM documentation

Validation and Testing

Post-Update Checks

Collaborator Self-Verification:

Provide this checklist to the collaborator:

1. Log in to Mixpanel at https://mixpanel.com
2. Verify the project switcher dropdown shows expected projects
3. For each project you should have access to:
   a. Navigate to a test report or dashboard
   b. Attempt to create a new Insight (should work for Analyst/Admin, fail for Viewer)
   c. Try accessing Lexicon (should work for Admin only)
   d. Test Data Pipeline access if Admin (should see Pipelines tab)
4. Confirm you do NOT see projects outside your scope
5. Reply to this email confirming successful access

Admin Verification Steps:

1. Activity Log Confirmation:
   - Settings → Activity Log → Filter by member
   - Verify "Member role changed" event exists
   - Note the timestamp and role changes

2. Permission Smoke Test:
   - Ask collaborator to perform a test action
   - Admin: Create a test Lexicon entry, then delete it
   - Analyst: Create a temporary report, share it, delete it
   - Viewer: View an existing report, attempt to edit (should fail)

3. API Access Test (for Admin roles):
   curl -X GET \
     https://mixpanel.com/api/2.0/events/properties/top \
     -u [COLLABORATOR_API_SECRET]: \
     -d '{"event": "Page Viewed", "name": "page_name"}'

   Should return property values if permissions are correct

Common Update Failures

Error: "You don't have permission to modify this user"

Cause: Your account lacks Organization Admin privileges Solution: Request an Organization Owner or Admin to make the change

Error: "User not found in organization"

Cause: The collaborator hasn't accepted their invitation yet Solution:

Resend the invitation email
Check spam folder
Verify the email address is correct
If using SSO, confirm the user exists in the IdP

SCIM Sync Failure After Manual Change

Symptom: Role reverts to previous state after 40 minutes Cause: SCIM provisioning overrides manual changes Solution:

Update the IdP group membership instead
Wait for next SCIM sync cycle
Verify in Mixpanel UI

Project Doesn't Appear for User

Troubleshooting:

Verify you saved changes (check for "Unsaved Changes" warning)
Ask collaborator to log out and log back in
Check if project was recently created (may take 5 min to appear)
For SSO users, verify the SCIM mapping includes the project

Documentation Requirements

IAM Change Record Template

## Mixpanel Access Update

**Date:** 2024-01-15
**Requestor:** Jane Smith (Product Manager)
**Approver:** John Doe (VP Engineering)
**Ticket:** IAM-2847

### User Details
- **Email:** collaborator@agency.com
- **Name:** Alex Thompson
- **Organization:** Acme Corp Mixpanel

### Changes Made

**Organization Role:**
- Previous: Member
- New: Member (no change)

**Project Access:**

| Project | Previous Role | New Role | Justification |
|---------|---------------|----------|---------------|
| Web-Production | Analyst | Viewer | Implementation complete; ongoing reporting only |
| iOS-Production | Analyst | Viewer | Implementation complete; ongoing reporting only |
| Web-Staging | Admin | No Access | No longer in scope per SOW amendment |

### Implementation Method
- [ ] Manual UI update
- [X] SCIM sync via Okta
- [ ] API automation

### Verification
- [X] Activity Log reviewed
- [X] Collaborator confirmed access
- [X] Project access tested
- [X] Audit export saved to: /compliance/mixpanel/2024/IAM-2847/

### Related Actions
- Rotated API secret for Web-Production project
- Removed collaborator from "Mixpanel-Staging-Admins" Okta group
- Updated SOW access appendix

**Reviewed by:** Security Team (Sarah Jones)
**Next Review:** 2024-04-15 (quarterly check)

Compliance Evidence Checklist

For each update, retain:

Before Screenshot: Mixpanel Members page showing previous roles
After Screenshot: Mixpanel Members page showing updated roles
Activity Log Export: JSON or CSV showing the role change event
Email Confirmation: Collaborator acknowledging new access
Approval Record: Email or ticket showing authorization for the change
SCIM Logs (if applicable): IdP provisioning logs confirming sync

Store in: /compliance/[platform]/[year]/[ticket-number]/

Troubleshooting

Collaborator Reports Missing Projects

Diagnosis:

Verify the collaborator's email matches exactly in Mixpanel
- SSO email vs. manually added email can differ (capitalization, aliases)
Check if projects were added but role is "No Access"
Confirm the collaborator is logging in to the correct organization
- Users with multiple org access may land in wrong org by default

Resolution:

1. Settings → Members → Search for collaborator
2. Review "Project Access" section
3. If project is missing:
   - Click "+ Add Project"
   - Select the project
   - Assign appropriate role
4. If project shows "No Access":
   - Change role to Analyst or Viewer
5. Save and ask collaborator to refresh browser

Changes Take Effect Slowly

Expected Propagation Times:

Manual UI changes: Immediate (refresh browser)
SCIM sync: 40 minutes (typical), up to 1 hour
API updates: Immediate, but may require cache clear
Cross-region projects: Up to 5 minutes for data residency reasons

Force Refresh:

User Actions:
1. Log out of Mixpanel completely
2. Clear browser cache for mixpanel.com
3. Log back in
4. Hard refresh (Ctrl+Shift+R or Cmd+Shift+R)

Admin Actions:
1. Make a trivial change to the user (add/remove a project, even briefly)
2. Save changes to trigger a sync
3. Revert to intended configuration

Analyst Can't Create Cohorts

Symptoms:

Analyst role should allow cohort creation, but collaborator sees "Permission Denied"

Causes:

Data governance policy: Organization Admin may have restricted cohort creation to Admins only
- Check: Settings → Data Governance → Cohort Settings
Project-specific override: Some projects disable cohort creation entirely
Cached permissions: Role was recently upgraded from Viewer

Resolution:

1. Verify actual role: Settings → Members → Confirm "Analyst" badge
2. Check governance policy: Settings → Data Governance
   - If "Only Admins can create cohorts" is enabled, either:
     a. Disable the policy (if appropriate), OR
     b. Upgrade collaborator to Admin
3. Cache issue: Have collaborator log out, clear cookies, log back in

SCIM Deprovisioning Doesn't Remove User

Symptoms:

User removed from IdP groups, but still has Mixpanel access after 1+ hour

Diagnosis:

# Check SCIM configuration
1. Organization Settings → SSO/SCIM
2. Review "Deprovisioning Behavior" setting
3. Options:
   - Suspend user (keeps account, removes access)
   - Delete user (fully removes account)

Common Misconfigurations:

IdP: Deprovisioning is disabled in app settings
- Okta: Check Application → Provisioning → Deprovisioning → "Deactivate Users" must be checked
- Azure AD: Provisioning → Settings → Scope → Should include "Remove"
Mixpanel: SCIM endpoint expects DELETE verb but IdP sends UPDATE with status=inactive
- Verify via SCIM logs which verb your IdP uses

Manual Override:

If SCIM fails to deprovision:

1. Settings → Members → Find user
2. Click "Remove from Organization"
3. Confirm removal
4. File a support ticket with your IdP to fix SCIM deprovisioning

Service Account Token Updates

When granting Admin access or adding Data Pipeline permissions:

Review Existing Tokens:

# List all project tokens
curl -X GET \
  https://mixpanel.com/api/app/projects/[PROJECT_ID]/tokens \
  -u [SERVICE_ACCOUNT_USERNAME]:[SERVICE_ACCOUNT_SECRET] \
  | jq '.[] | {id, name, created_at, last_used}'

Rotate Tokens Created by the Collaborator:

If the collaborator previously had Admin access and created service account tokens:

Identify which integrations use those tokens
Generate new tokens with appropriate updated permissions
Update integrations (data pipelines, Segment connections, reverse ETL tools)
Revoke old tokens
Document the rotation in your secrets management system

Alert and Report Subscriptions

When Downgrading from Analyst to Viewer:

Navigate to Alerts tab in each project
Filter by collaborator's email
Review subscriptions:
- Transfer ownership to client team member, OR
- Delete alerts no longer needed
Repeat for Boards → Scheduled Reports

When Upgrading to Admin:

Consider adding the collaborator to critical alert distributions:

Data ingestion failures
Tracking plan violations
Data Pipeline errors
Quota warnings

Data Pipeline Access Dependencies

AWS S3 Exports:

If the collaborator manages Data Pipelines to S3:

1. Verify they have AWS IAM credentials for the destination bucket
2. Update Mixpanel Data Pipeline configuration with latest credentials
3. Test export with sample data
4. Document which AWS IAM user/role corresponds to their Mixpanel access

Google Cloud BigQuery:

1. Ensure collaborator has BigQuery dataset permissions
2. For new Admin access, create a GCP service account
3. Grant BigQuery Data Editor role
4. Add service account to Mixpanel Data Pipeline configuration
5. Verify Mixpanel can write to intended dataset

Snowflake Warehouses:

-- Grant Mixpanel service account (used by collaborator) write access
GRANT USAGE ON WAREHOUSE MIXPANEL_WH TO ROLE MIXPANEL_ROLE;
GRANT USAGE ON DATABASE ANALYTICS TO ROLE MIXPANEL_ROLE;
GRANT USAGE ON SCHEMA ANALYTICS.MIXPANEL TO ROLE MIXPANEL_ROLE;
GRANT INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA ANALYTICS.MIXPANEL TO ROLE MIXPANEL_ROLE;

-- Document which Mixpanel user manages this pipeline
COMMENT ON SCHEMA ANALYTICS.MIXPANEL IS 'Managed by collaborator@agency.com - Mixpanel Admin';

Appendix: Common Role Update Patterns

Pattern 1: Implementation → Ongoing Support

Timeline: 3-month implementation, then 12-month maintenance contract

Initial (Months 1-3):
- Organization Role: Member
- Web-Staging: Admin (instrumentation testing)
- Web-Production: Admin (initial event setup and Lexicon)
- iOS-Staging: Admin
- iOS-Production: Admin

Transition (Month 4):
- Organization Role: Member (no change)
- Web-Staging: No Access (testing complete)
- Web-Production: Analyst (maintenance and reporting)
- iOS-Staging: No Access
- iOS-Production: Analyst

Offboarding (Month 16):
- Remove all access
- Transfer report ownership to client
- Rotate all API secrets

Pattern 2: Seasonal Campaign Access

Pre-Campaign (2 weeks before launch):
- Add Project Access: Holiday-Campaign-2024
- Role: Analyst (dashboard creation)

During Campaign (4 weeks):
- No change (monitor performance)

Post-Campaign (1 week after):
- Downgrade to Viewer (historical reference)
- After 90 days: Remove access entirely

Pattern 3: Security Incident Response

Incident Detected:
- Temporarily elevate to Admin (audit log review)
- Grant access to all projects (scope investigation)
- Document approval from VP Engineering and Security Lead

Investigation Period (2-5 days):
- Collaborator reviews Activity Logs
- Identifies compromised service account
- Coordinates credential rotation

Resolution:
- Downgrade back to standard Analyst role
- Remove temporary project access
- Document findings in incident report

返回顶部