mParticle User Management Guide

• Model type: role-based
• Description: mParticle uses a role-based access control model with predefined roles (Admin, User, Read-Only) applied at the account and workspace level. Workspace-level role assignments allow different permissions per workspace for the same user. No custom role creation is documented.
• Custom roles: No
• Custom roles plan: Not documented
• Granularity: Role assignments are per-workspace; roles are predefined and not customizable. Admins can assign users to specific workspaces with specific roles.

1. Log in to app.mparticle.com as an Admin.
2. Navigate to Settings (gear icon) → Users.
3. Click 'Invite User'.
4. Enter the user's email address.
5. Select the role (Admin, User, or Read-Only) for the account level.
6. Optionally assign the user to specific workspaces and set workspace-level roles.
7. Click 'Send Invitation'.
8. The invited user receives an email and must accept the invitation to activate their account.

Required fields: Email address, Account-level role

Watch out for:

• Users must accept the email invitation before they can log in; there is no way to force-activate an account.
• If SSO is enforced, users must authenticate via the configured IdP; password-based login may be disabled.
• Workspace assignments are optional at invite time but must be configured for the user to access any workspace data.

• Can delete users: Yes
• Delete/deactivate behavior: Admins can remove users from the account via Settings → Users. The official docs use 'remove' rather than 'deactivate'; removed users lose access immediately. It is not documented whether user records are soft-deleted or permanently purged.

1. Log in to app.mparticle.com as an Admin.
2. Navigate to Settings → Users.
3. Locate the user to be removed.
4. Click the options menu (ellipsis or similar) next to the user.
5. Select 'Remove User' or equivalent action.
6. Confirm the removal.

Watch out for:

• No documented 'deactivate without delete' option; removal appears to be permanent account-level action.
• If the removed user was the sole Admin, the account may lose admin access - ensure at least one other Admin exists before removing.
• SSO-provisioned users removed from the IdP may still appear in mParticle until manually removed from the mParticle Users settings, as there is no SCIM deprovisioning.

• Where to check usage: Settings → Usage (data volume and event consumption); user count visible at Settings → Users.
• How to identify unused seats: No documented automated inactive-user detection. Admins must manually review the Users list and cross-reference last login activity if available.
• Billing notes: mParticle uses value-based, volume-based credit pricing. There is no per-seat or per-user charge. Adding or removing users does not directly affect the invoice. Contract costs are based on pre-purchased event/data credits, typically negotiated annually. Average reported contract cost is approximately $156,000/year.

mParticle uses volume-based credit pricing with no per-seat charge, so adding or removing users does not directly affect your invoice. That said, the absence of SCIM means offboarding requires a manual admin action in the mParticle Users settings every time an employee leaves - IdP removal alone is not sufficient.

Without last-login visibility or automated inactive-user detection, access reviews require admins to manually audit the Users list, which compounds the operational burden at scale.

Practitioners consistently flag two friction points: the permission model lacks the granularity needed to restrict specific actions (such as preventing modification of live connections) without dropping a user to full Read-Only, and workspace-level role configuration is non-intuitive for large teams.

The absence of an audit log or last-login timestamp makes it difficult to identify stale accounts during periodic access reviews. SSO-provisioned users removed from the IdP continue to appear in mParticle until manually deleted, which is a documented offboarding risk raised across G2 reviews.

Common complaints:

• Users report that the permission model lacks granularity - there is no way to restrict access to specific features (e.g., prevent a user from modifying live connections) without giving full User or Read-Only access.
• Reviewers on G2 and similar platforms note that removing SSO-provisioned users requires manual cleanup in mParticle because there is no SCIM deprovisioning, creating offboarding risk.
• Some users note that workspace-level role management is not intuitive and requires multiple steps to configure correctly for large teams.
• Lack of an audit log or last-login visibility makes it difficult to identify inactive users for access reviews.

mParticle is appropriate for teams that can accept manual provisioning and deprovisioning workflows. The role model - Admin, User, and Read-Only - covers standard access tiers, and workspace-scoped assignments give per-project flexibility.

Teams that require automated lifecycle management across every app in their environment, or that operate under strict access-review compliance requirements, should plan for a custom integration layer to compensate for the missing SCIM support.

Bottom line

mParticle's user management is functional but entirely manual: no SCIM, no automated deprovisioning, and no native inactive-user detection.

The platform's value-based pricing means user count is not a cost lever, but the operational overhead of manual offboarding and access reviews is real - particularly for organizations managing large or frequently changing teams across multiple workspaces.

Teams that need IdP-driven lifecycle automation will need to build or procure a custom integration against the Platform API.