Medusa User Management Guide

• Model type: custom-roles
• Description: Out of the box, Medusa's admin dashboard treats all invited users as administrators with equivalent access. The User Module exposes a data model and API that developers can extend to implement custom roles and permission sets, but no pre-built granular role tiers (e.g., read-only, manager) are provided in the default UI.
• Custom roles: Yes
• Custom roles plan: Available in the open-source build via custom implementation; no paid plan required, but requires developer effort.
• Granularity: Coarse by default (single admin role); fine-grained control is possible only through custom development against the User Module API.

1. Log in to the Medusa admin dashboard.
2. Navigate to Settings → Team.
3. Click the 'Invite Users' button.
4. Enter the email address of the person to invite.
5. Click 'Send Invite'. An invitation link is generated.
6. Share the invitation link with the invitee (Medusa does not send the email automatically in all self-hosted setups; the link must be copied and sent manually unless an email provider is configured).
7. The invitee opens the link, sets a name and password, and completes account creation.

Required fields: Email address

Watch out for:

• Medusa does not automatically email the invitation in self-hosted deployments unless an email notification plugin (e.g., SendGrid) is configured. The admin must manually copy and share the invite link.
• Invitation links expire; if the invitee does not accept in time, a new invite must be generated.
• All invited users receive full admin access by default; there is no role selector in the invite flow without custom development.
• No bulk invite or CSV import is available in the default admin UI.

• Can delete users: Yes
• Delete/deactivate behavior: Medusa allows removing (deleting) a user from the Team settings page. The official user guide refers to this action as 'removing' a user. There is no documented native deactivation/suspension state in the default admin UI; removal is a hard delete of the user's admin access.

1. Log in to the Medusa admin dashboard.
2. Navigate to Settings → Team.
3. Locate the user to remove.
4. Click the action menu (three dots) next to the user.
5. Select 'Remove User' and confirm the action.

Watch out for:

• There is no built-in deactivation or suspension option; the only option is full removal.
• Removing the only admin user can lock out access to the admin dashboard; Medusa does not prevent deletion of the last admin in all configurations.
• API keys or tokens associated with the removed user are not automatically invalidated; manual cleanup is required.
• Medusa Cloud billing implications for user removal are not publicly documented in detail.

• Where to check usage: Settings → Team (shows current list of admin users in the dashboard).
• How to identify unused seats: No built-in last-login timestamp or activity report is available in the default admin UI. Unused accounts must be identified by reviewing the Team list manually or querying the database/API directly.
• Billing notes: The open-source self-hosted version has no per-seat billing. Medusa Cloud seat limits and overage policies are not publicly documented in detail; contact Medusa for Cloud plan specifics.

Invitation emails are not sent automatically in self-hosted deployments unless an email provider such as SendGrid is configured; without one, admins must manually copy and distribute invite links for every new team member. There is no bulk invite or CSV import, so each user must be onboarded individually.

No last-login timestamp or activity report is available in the default UI, meaning unused account cleanup depends entirely on manual review of the Team list or direct database queries.

The most consistent friction point reported by Medusa operators is the absence of a built-in granular role system: every invited user receives full admin access, which blocks stores that need limited-privilege staff accounts.

Self-hosted email configuration is a close second-teams that skip it discover the gap only when an invite link goes unsent.

Community members also flag that removing the last admin user is not reliably prevented, creating a real lockout risk, and that API keys tied to a removed user are not automatically invalidated.

Common complaints:

• Users report that the default Medusa admin has no granular role system, meaning all team members get full admin access, which is a blocker for stores that need read-only or limited-access staff accounts.
• Self-hosted deployments require manual configuration of an email provider to send invitation emails; without it, admins must copy and share invite links manually, which is error-prone.
• No built-in last-login or activity tracking makes it difficult to identify and clean up inactive admin accounts.
• No CSV or bulk import for users; each team member must be invited individually.
• No native SSO or SCIM support; integrating with identity providers requires custom development.
• Community members note that removing the last admin user is not reliably prevented, creating a risk of locking out the admin dashboard.

Every app that grows beyond a handful of trusted admins will hit the same ceiling: flat permissions, no native identity provider integration, and no audit trail without custom code. Medusa's manual user management is workable for small, technically capable teams comfortable with a single admin role and a self-hosted setup they control.

Teams that need granular roles, SSO, SCIM, or activity auditing should budget developer time before onboarding staff, not after.

Bottom line

Medusa gives you a functional admin team management UI out of the box, but it is deliberately minimal. Every app that scales beyond a small trusted team will encounter the same gaps: flat permissions, no native identity provider integration, and no built-in audit trail.

The open-source model means those gaps are solvable, but solving them requires engineering effort that should be scoped and planned explicitly.