Magento User Management Guide

• Model type: role-based
• Description: Magento uses a role-based access control (RBAC) system built on an Access Control List (ACL). Each admin user is assigned exactly one role. Roles define which ACL resources (menu items, actions, data scopes) the user can access. The built-in 'Administrators' role grants unrestricted access to all resources. All other roles are custom-defined by selecting from a hierarchical tree of ACL resources. Roles can optionally be scoped to specific websites or store views.
• Custom roles: Yes
• Custom roles plan: All editions (Open Source, Commerce On-premise, Commerce Cloud)
• Granularity: Granular – ACL resource tree covers individual menu sections, sub-sections, and specific actions (e.g., view orders vs. create credit memos vs. manage order comments). Hundreds of individual ACL resources available. Store-view/website scoping available at role level.

1. Log in to the Admin panel with an account that has System → Permissions → All Users access.
2. Navigate to System → Permissions → All Users.
3. Click 'Add New User' button.
4. In the 'Account Information' tab, enter: User Name, First Name, Last Name, Email, Password, Password Confirmation.
5. Set 'This account is' to 'Active'.
6. Optionally enable 'Interface Locale' preference.
7. Click the 'User Role' tab and select the role to assign to this user.
8. Click 'Save User'.
9. The new user receives no automatic email notification by default; credentials must be communicated manually unless a custom extension or SMTP configuration triggers a welcome email.

Required fields: User Name (unique), First Name, Last Name, Email (unique), Password, Password Confirmation, Role assignment (user cannot log in without a role)

Watch out for:

• A user without an assigned role can be saved but cannot log in to the Admin panel - the role assignment is functionally required even though the UI allows saving without one.
• Two-factor authentication (2FA) is enabled by default in Adobe Commerce 2.4+. New users must configure their 2FA provider on first login. Admins can reset a user's 2FA configuration via System → Security → 2FA but cannot pre-configure it for them.
• Passwords must meet the configured minimum security requirements (minimum length, required character classes). Default minimum is 7 characters with mixed case and numbers.
• Email addresses must be unique across all admin accounts in the same installation.
• There is no native bulk user import via CSV in the Admin UI. Bulk creation requires direct database manipulation or a third-party extension.
• For Adobe Commerce Cloud, store Admin users and cloud project users are managed in two separate systems and must be added independently.

• Can delete users: Yes
• Delete/deactivate behavior: Admin users can be both deactivated (set to Inactive status) and permanently deleted in Magento/Adobe Commerce. Deletion is available via the Admin panel grid or the user edit form. However, the primary administrator account created during installation is protected and cannot be deleted. Deleting a user is irreversible; the account and its direct record are removed from the admin_user table.

1. Navigate to System → Permissions → All Users.
2. Click on the user's name to open their account.
3. In the 'Account Information' tab, change 'This account is' from 'Active' to 'Inactive'.
4. Enter your own admin password in the 'Current User Identity Verification' field when prompted.
5. Click 'Save User'.
6. The user is immediately unable to log in but the account record is retained.

Watch out for:

• Deleting an admin user is permanent and cannot be undone through the UI. There is no soft-delete or recycle bin for admin accounts.
• The system requires you to verify your own admin password before saving changes to another user's account (identity verification prompt), including deactivation.
• If a user is the only member assigned to a custom role, deleting the user does not delete the role - the role remains and can be reassigned.
• Active admin sessions for a deactivated user are not immediately terminated in all Magento versions. The session may remain valid until it expires naturally unless the session storage is cleared.
• For Adobe Commerce Cloud, deactivating a store Admin user does not remove their cloud project access. Cloud project access must be revoked separately via the Cloud Console or CLI.
• The primary/first admin account (created during installation) cannot be deleted via the Admin UI.

• Where to check usage: System → Permissions → All Users (shows all admin accounts and their Active/Inactive status). No built-in last-login report in the standard Admin UI; last login timestamp is stored in the admin_user table (last_login column) and can be queried directly in the database.
• How to identify unused seats: No native 'inactive users' report in the Admin UI. To identify unused accounts, query the admin_user table directly: SELECT username, email, is_active, last_login FROM admin_user ORDER BY last_login ASC. Accounts with null or old last_login values and is_active=1 are candidates for deactivation.
• Billing notes: Adobe Commerce licensing is not seat-based. Adding or removing admin users has no direct impact on licensing costs. License fees are negotiated annually based on GMV tiers and AOV. Renewals and tier changes are managed through Adobe account representatives, not through the Admin panel.

Magento admin user seats carry no per-seat cost on any edition. Open Source, Commerce On-premise, and Commerce Cloud all include unlimited admin users; licensing is based on GMV and AOV tiers, not headcount. This means adding or removing admin accounts has zero direct impact on your license bill.

The real cost is operational. There is no native last-login report in the Admin UI, so identifying stale accounts requires a direct database query against the admin_user table (last_login column).

Without that query, dormant accounts with broad ACL roles accumulate silently across every app connected to the store, and deactivating a user does not immediately kill their active session - it persists until natural expiry unless session storage is manually cleared.

The most consistent friction point reported by Magento operators is the dual-system problem: store Admin users and Commerce Cloud project users are managed in two separate places with no synchronization.

Offboarding a staff member requires manual action in both systems, and it is easy to miss one.

Other recurring issues include the absence of a bulk admin user import (CSV import is not available natively; bulk creation requires database manipulation or a paid Marketplace extension), no built-in stale-account report, and per-user 2FA resets that cannot be batched.

Session persistence after deactivation is also flagged as a security concern in older Magento 2.x versions where session storage is not centralized.

Common complaints:

• No native SCIM provisioning for Okta or other IdPs in the Adobe Commerce ecosystem; SCIM requires third-party Marketplace extensions or is limited to Azure AD/Google Workspace via Adobe Admin Console for IMS-enabled Commerce Cloud deployments.
• No built-in last-login report or unused account identification tool in the Admin UI; identifying stale accounts requires direct database queries.
• No native bulk admin user import via CSV; bulk creation requires database manipulation or paid extensions.
• Active admin sessions are not immediately invalidated when a user is deactivated; sessions persist until natural expiry unless session storage is manually cleared.
• Two-factor authentication reset must be done per-user by an admin; there is no bulk 2FA reset or bypass for onboarding multiple users simultaneously.
• Store Admin user management and Adobe Commerce Cloud project user management are entirely separate systems with no synchronization, requiring duplicate effort when onboarding or offboarding staff.
• The single-role-per-user limitation means complex permission requirements require creating many granular roles rather than combining multiple roles per user.
• No native audit log UI for tracking which admin performed which action; audit logging requires third-party extensions or custom development.

Manual admin user management in Magento is workable for small teams with stable rosters. The ACL system is genuinely granular - hundreds of individual resource nodes, website/store-view scoping at the role level - so access can be tightly controlled once roles are designed.

It breaks down at scale or during rapid onboarding and offboarding cycles. No native SCIM means every app that needs provisioning sync requires either a third-party Marketplace extension or a custom integration. The split between store Admin and Cloud Console access doubles the manual work for every hire and departure on Commerce Cloud deployments.

Teams running more than a handful of admin users, or operating across multiple store views, will hit the limits of the native tooling quickly.

Bottom line

Magento's native admin management gives you a capable RBAC model with granular ACL controls and no seat-based cost, but it was not designed for automated lifecycle management.

There is no native SCIM, no bulk import, no last-login report in the UI, and no session invalidation on deactivation. For Commerce Cloud deployments, the store Admin and cloud project access layers are fully decoupled, requiring duplicate effort on every onboarding and offboarding.

Teams that need to enforce consistent access hygiene across every app in their stack - and keep audit trails without running raw SQL - will find the native tooling insufficient without additional automation.