Medusa JS admin panel: where store management breaks down
The stock Medusa JS admin panel covers the basic scenario: products, orders, customers, warehouses. As long as the catalog has a hundred items and one region, everything works.
As soon as there are several warehouses, tens of thousands of SKUs, and employee roles, bottlenecks start to show up.
The first is slow loading of product lists. The admin panel requests relations (variants, prices, inventory, collections) and, without explicitly specifying fields, pulls the entire object.
With 20-30 thousand items, the page takes tens of seconds to open, filters "freeze," and the manager goes off to work in a spreadsheet.
The second is manual operations: bulk price editing, category assignment, discount recalculation are done one product at a time, because there are no built-in bulk actions.
The third and most costly is inventory discrepancies. Orders, returns, and write-offs live in different places, synchronization with 1C or a marketplace runs on a schedule, and at any given moment the admin panel shows something different from what is actually in the warehouse.
The result is selling what you do not have, and manual reconciliation. The fourth is the lack of the widgets you need: a department has its own metrics (turnover, cancellation rate, delivery status), but you cannot embed them into the dashboard without editing code.
Customizing the Medusa admin panel solves this in a targeted way: configurable queries with server-side pagination and filters, bulk operations, widgets for specific roles, a single source of truth for inventory. Let's break down how this is addressed.
What a refined admin panel delivers: widgets, roles, speed
Custom widgets instead of core modifications
The stock panel covers basic scenarios, but as soon as custom entities appear — inventory, a loyalty program, approvals — the team starts modifying the core.
Widgets in Medusa 2 are connected through extension points and live separately from the main codebase: a platform update doesn't break the customizations.
In practice, this reduces the amount of code that needs to be re-verified with every upgrade by orders of magnitude — instead of editing dozens of files, a single isolated module remains.
Roles and permissions: access by operations, not "everyone gets everything"
Access control is built on roles with a set of permissions for specific actions: a manager can see orders but doesn't touch prices and payment settings; a content editor works with product cards without access to finances.
Permissions are checked both in the interface and on the API side — a hidden button doesn't replace a server-side check. This eliminates a whole class of incidents where an employee with excessive permissions accidentally changes prices or deletes an order.
Query optimization: the panel stops "freezing" on large catalogs
The main cause of a slow admin panel is lists that pull related data in full. We limit the selection of fields, add pagination and indexes for real filters, and cache reference data.
An order list with tens of thousands of records opens in seconds instead of tens of seconds, and filters by status and date stop blocking the interface.
| Option | When it fits | Limitations |
|---|---|---|
| Widgets via extension points | Custom entities and scenarios | Require careful data typing |
| Fork and core modification | A one-off non-standard scenario | Every update means manually porting the changes |
| External panel on top of the API | A custom interface for a narrow role | Duplication of logic and authorization |
To monitor performance, we use query profiling on real data volumes — Medusa provides metrics for every API call, and from them you can see which part is slowing things down.
How we implement customizations: stages of engineering work
We start with an audit of the admin panel: we look at which entities and relationships already exist in the data model, how the existing extensions are structured, and where the rights of roles diverge from the actual responsibilities of employees.
The output is a map of extension points and a list of scenarios that are broken now or will break after the customization.
Next, we design the widget integration scheme: which blocks are embedded in the order card, which live as a separate page, what pulls data from external systems, and what writes back.
- Audit of the admin panel and data model. We record the current entities, custom fields, extensions, and discrepancies between role rights and the actual tasks of employees.
- Widget integration scheme. We determine the embedding points, data sources, and the method of communication with external services — through standard extensions or a separate layer on top.
- Access role configuration. We delimit rights by role: who sees the entire order, who sees only their part, who manages products and prices. We verify that the restrictions work at the query level, not just in the interface.
- Scenario verification. We run through end-to-end paths: order placement, return, status change, bulk operations. Separately — behavior during external service failures and repeated requests.
- Optimization. We remove unnecessary queries on lists, add indexes for frequent filters, and check response time on large datasets.
- Deployment. We assemble the environment configuration, migrations, and variables, bring it up on a staging environment, then on the production environment with the ability to roll back.
- Configuration handover. We deliver the configured admin panel, the integration scheme, access policies, and documentation on typical operations.
Each stage ends with a verifiable result: an extension map, a scheme, a rights matrix, a scenario report, an environment configuration. Describe your task — we will come back with an estimate and a plan for your environment.
How is a custom widget different from modifying the Medusa core?
A custom widget is a separate module that connects to the medusa js admin panel through an extension point and lives on top of the core without changing its files.
Modifying the core is when an engineer opens the sources of @medusajs/admin or the server packages and edits them directly: rewrites a route, adds a field to a model, changes the checkout logic.
Externally the result is the same — a new button in the interface or a new field in the product card. The difference shows up not at the moment of development, but at the moment of the first update.
The extension architecture is built on the premise that the core remains an unchanged artifact from the package registry.
A widget is registered in a separate configuration file, gets access to the needed data through public hooks and APIs, and knows nothing about the internal structure of neighboring modules.
When a new Medusa branch is released, you update the package version and rebuild the admin panel — your code stays in place because it was never embedded in someone else's.
When modifying the core, an update turns into a manual merge: you have to compare your changes with the new version line by line, port them over again, and check that nothing broke.
The more modifications have accumulated, the more expensive each update becomes and the higher the chance that the team decides "let's not touch it for now" — and stays on an outdated branch with known vulnerabilities.
The risks of modifying the core accumulate unnoticed. The first change seems harmless, but each subsequent one layers on top of the previous, and after several iterations no one remembers why a particular method was overridden.
Tests written for the standard behavior start failing on your build, and bug reports from the vendor cannot be applied because the problem cannot be reproduced on a modified core.
A widget eliminates this entire class of problems: it is isolated, it can be disabled with a single line in the configuration, and the system's behavior returns to the reference one.
The practical rule is simple: everything that can be done through a widget, an event, or a separate module is done that way.
Direct modification of the core is justified only where a public extension point truly does not exist — and then it is formalized as a patch with a separate test and a marker that the team is obliged to review with every update. Support for updates in this case becomes a manageable process rather than a quarterly fire drill.
Case study: sped up the admin panel and removed manual operations
The project is a marketplace on Medusa with a catalog of several tens of thousands of products and a dozen suppliers.
Operators complained that the order list took 8-12 seconds to open, and some routine actions — reconciling stock, setting statuses, re-issuing product cards after import — were done by hand in spreadsheets.
Errors from manual entry accumulated over weeks: discrepancies in stock, duplicated items, lost statuses.
What we did
We improved the admin panel rather than rewriting it: we added widgets to the order and product cards, moved frequent actions into buttons with confirmation, and switched heavy lists to server-side pagination and filters on the API side.
Supplier import became a background job with a log — the operator sees what went through, what failed and why, instead of waiting at the screen.
Metrics before and after
| Metric | Before | After |
|---|---|---|
| Order list load time | 8-12 s | 1-2 s |
| Share of manual operations | ~40% | ~10% |
| Stock discrepancies | weekly | isolated cases |
| Supplier import processing | manually, hours | in the background, minutes |
Manual operations did not disappear completely — they remained where a human decision is needed. But the routine went into automation with a log: if something went wrong, you can see at which step and with what data.
What this gave
The team stopped spending time on reconciliation and sorting out discrepancies — the freed-up hours went into working with the assortment and suppliers.
The class of errors "the human forgot/mixed up" practically disappeared: where things used to be corrected by hand, now a check at the input triggers.
We worked on the Medusa stack — Medusa provides a ready-made admin panel and API, so the improvements were layered on top without rewriting the core. If you have a similar situation — describe the task, and we will come back with an estimate and a plan.
Compatibility, migration, and rollback: what to discuss before the start
Before starting, it is important to establish how the Medusa admin panel will fit into the current environment: where the database lives, how authentication is structured, and who accesses the interface and with which roles.
If the project already has its own authentication layer or an external login provider, we plan the integration in advance — otherwise, after deployment, session conflicts and duplicate accounts surface.
We discuss data migration separately: we transfer the catalog, orders, and settings in a way that does not interrupt the store's operation.
What if a rollback is required? We prepare the rollback plan before the first change in production: we record the database recovery point, version the configuration, and keep the previous working release available for return.
If something goes wrong after the rollout, we return to the recorded state within minutes rather than rebuilding everything from scratch.
What about access? We delineate roles and permissions on the principle of least privilege: a manager sees orders but does not touch settings, an administrator manages the catalog, and a developer gets access to the configuration. We transmit all keys and credentials through a secure channel, not in chat.
Can migration be done without taking the site down?
Yes. We transfer data in stages: first we synchronize the catalog and settings to a copy, verify the integrity of relationships, then switch traffic during a short window. Customers continue to place orders, and we reconcile discrepancies using checksums before the final switch.
Upon completion, you receive a complete package:
- configuration of widgets and custom fields for the admin panel;
- role schema and access rights matrix;
- data migration scripts with a description of the launch order;
- deployment and environment setup instructions;
- backup and recovery regulations;
- rollback plan with recovery points;
- documentation for connected integrations and external services.
Describe your current infrastructure and task — we will get back to you with an estimate, migration plan, and timeline.
Implementation phase timelines: from audit to handover
Timelines depend not on team size, but on the state of the current setup: the fewer manual operations and "sticking points" between systems in the project, the shorter each phase.
Below is a duration guideline for a typical project where the Medusa 2 admin panel is being customized and taken to production. The estimate is refined after the audit: the discrepancy usually comes not from development, but from approvals and access.
The phases overlap: design begins before the audit is completed, and testing runs in parallel with final development. This shortens the overall implementation timeline by roughly a third compared to a sequential launch.
We fix the duration of the phases in the implementation plan so the client can see at which step the project is and what is required from them as input.
If part of the work has already been done or the integrations are standard, the timelines are shortened. If data migration from an old system or non-standard role scenarios are required, we add a buffer.
We provide an exact estimate after the audit: describe the task, and we will come back with a plan and timelines for each phase.
