commercetools User Management Guide

• Model type: hybrid
• Description: commercetools uses a team-based, role-driven permission model within the Merchant Center. Users are invited into an organization and then added to one or more teams. Each team is scoped to one or more projects. Within a team, users are assigned built-in roles (Viewer, Editor, Key User, Developer, Administrator) or custom granular permission sets that control access to specific resource types. API access (for integrations) is governed separately via OAuth 2.0 API clients with explicit scopes, independent of Merchant Center user roles.
• Custom roles: Yes
• Custom roles plan: Not documented
• Granularity: Resource-type level (e.g., Orders, Products, Customers, Discounts, Stores) with separate read and write toggles per resource.

1. Log in to the Merchant Center at https://mc.commercetools.com/.
2. Navigate to the Organization Settings (top-right organization menu).
3. Select 'Teams & Permissions'.
4. Select the team you want to add the user to, or create a new team.
5. Click 'Invite member' (or 'Add member' if the user already exists in the organization).
6. Enter the user's email address.
7. Select the role(s) to assign within that team.
8. Click 'Send invitation'. The user receives an email invitation to join.

Required fields: Email address of the invitee, Team selection, Role assignment within the team

Watch out for:

• Invited users must accept the email invitation before they can log in; pending invitations can be resent or cancelled from the team settings.
• If SSO is enforced for the organization, users must authenticate via the configured IdP; password-based login is disabled for those users.
• A user must be added to at least one team with at least one role to access any project resources.
• Inviting a user to a team does not automatically grant them access to other projects; separate team membership is required per project.

• Can delete users: Yes
• Delete/deactivate behavior: A user can be removed from a team (revoking their project access) without deleting their organization account. Full removal from the organization is also possible. Users can delete their own accounts from their profile settings. Organization Admins can remove users from teams and from the organization entirely via the Teams & Permissions settings.

1. Log in to the Merchant Center at https://mc.commercetools.com/.
2. Navigate to Organization Settings → Teams & Permissions.
3. Select the team the user belongs to.
4. Locate the user in the team member list.
5. Click the remove/delete icon next to the user's name.
6. Confirm the removal. The user immediately loses access to that team's project(s).
7. Repeat for each team the user is a member of to fully revoke all project access.
8. To remove the user from the organization entirely, navigate to the organization member list and remove them there.

Watch out for:

• Removing a user from a team does not remove them from the organization; they retain the ability to be re-added to teams until fully removed from the organization.
• The last Organization Admin cannot be removed; a replacement admin must be designated first.
• If SSO is configured, deprovisioning in the IdP prevents login but does not automatically remove the user from the Merchant Center organization; manual removal in the Merchant Center is still required (SCIM auto-deprovisioning is not documented as available).
• Pending invitations that have not been accepted should be cancelled separately if the invitation was sent in error.

• Where to check usage: Merchant Center → Organization Settings → Teams & Permissions (view all members and team assignments across the organization).
• How to identify unused seats: No built-in last-login reporting is documented in the Merchant Center UI. Administrators must manually review team member lists to identify users who may no longer need access. Activity logs are available via the Change History API for audit purposes.
• Billing notes: commercetools uses order-volume-based pricing (not GMV, not per-seat). Published starting prices are approximately $40,000/year for standard tiers and $150,000/year for premium tiers. User seat count does not directly drive billing under the standard pricing model, but enterprise contracts may include user-count terms. Pricing details require direct engagement with commercetools sales.

commercetools does not expose a last-login timestamp or built-in activity report in the Merchant Center UI. Identifying stale accounts requires manually reviewing team member lists across every project - there is no single organization-wide view that surfaces inactivity.

Change history is available via the Change History API for audit purposes, but that requires a separate query workflow rather than a dashboard scan.

Users must be added to each team per project individually; there is no global role assignment that propagates across all projects automatically. For organizations running multiple storefronts or regions as separate projects, this means every app requires its own team membership review during offboarding.

Pending invitations do not expire automatically, leaving open access windows for departed employees unless cancelled manually.

The most consistently reported friction point is the absence of SCIM support. When an employee is deprovisioned in an IdP, their Merchant Center session is blocked at login - but their organization membership and team assignments remain intact until an admin manually removes them.

This creates a gap between IdP offboarding and actual access revocation that requires a separate cleanup step every time.

Administrators also flag the identity model transition complexity when migrating from legacy commercetools identity to the current organization/team structure. The lack of per-user activity data compounds this: without last-login visibility, periodic access reviews rely entirely on manual cross-referencing against HR or directory systems.

Common complaints:

• Identity transition complexity when migrating from legacy commercetools identity to the newer organization/team model.
• No SCIM support documented, meaning IdP deprovisioning does not automatically remove users from the Merchant Center; manual cleanup is required.
• No built-in last-login or user activity reporting in the Merchant Center, making it difficult to identify stale accounts.
• Users must be manually added to each team per project; there is no global role assignment that spans all projects automatically.
• Pending invitations do not expire automatically, which can leave open invitations for departed employees.

The manual approach is workable for small, stable teams where project count is low and user churn is infrequent. The Merchant Center UI at Merchant Center → Organization Settings → Teams & Permissions covers the full invite, role assignment, and removal workflow without requiring any tooling beyond browser access.

The model breaks down at scale. Every app in a multi-project commercetools setup requires separate team membership management, and without SCIM or last-login data, offboarding accuracy depends entirely on process discipline rather than system enforcement. Organizations with frequent headcount changes or strict access review requirements will find the manual overhead significant.

Bottom line

commercetools gives administrators fine-grained control over who can access what within each project, but the absence of SCIM, last-login reporting, and cross-project role propagation means that access hygiene is a manual discipline.

Offboarding requires touching every team in every project the departing user belongs to, and IdP deprovisioning alone does not clean up Merchant Center membership.

For organizations where access review cadence matters, the gap between what the IdP knows and what the Merchant Center reflects is the central operational risk.