Hyvä Admin is a free, open-source Magento 2 module that provides a simpler way to build admin grids than the native UI Components framework. Grids are declared in a small XML file pointing at a repository method or custom data provider. It is released under OSL 3.0, it is independent of the Hyvä theme, and installing it leaves your existing grids untouched.
Two things worth clearing up immediately, because both cause confusion. This is not part of the Hyvä storefront theme and does not require it. And despite the repository description mentioning forms, the documentation is explicit that the module currently covers grids, with form creation noted as a future addition. Scope your work to grids today.
The problem it addresses
Anyone who has built a custom admin grid in Magento 2 knows the shape of this. UI Components are powerful and configurable, and the cost of that flexibility is a steep learning curve, a lot of XML spread across several files, and a debugging experience that involves working out which layer silently swallowed your configuration.
For a genuinely complex grid with intricate requirements, that power is justified. For the far more common case, which is showing records from one table with some columns, a filter, and a couple of actions, it is a great deal of machinery for a modest outcome. The module’s stated aim is making grids and forms in the adminhtml area fast to build without fighting the framework, and grids are where it delivers that today.
How a grid is declared
Two pieces, and that is the whole thing.
Layout XML carries an <update handle="hyva_admin_grid"/> declaration and a reference to the Hyva\Admin\Block\Adminhtml\HyvaGrid block.
A grid configuration file lives in [Module]/view/adminhtml/hyva-grid/ and defines the data source. That source is either a repository method you already have or a custom provider implementation you supply.
From there the defaults do the work. All fields on the record render as columns unless you narrow them with an inclusion or exclusion list. Paging, filtering, column customisation, and row and mass actions are configuration rather than code.
The practical consequence is that a working grid over an existing repository is a short XML file rather than a subdirectory of them. For internal tooling, that difference decides whether the tool gets built at all.
What you get, and what you do not
| Hyvä Admin | Native UI Components | |
|---|---|---|
| Grids | Yes, XML declaration over a repository or provider | Yes |
| Forms | Not yet, documented as future | Yes |
| Learning curve | Low | Steep |
| Configuration surface | One grid file plus layout XML | Multiple files across layers |
| Row and mass actions | Configurable | Configurable |
| Paging and filtering | Included | Included |
| Effect on existing grids | None, they are unchanged | n/a |
| Licence | OSL 3.0, free | Part of Magento |
| Ceiling | Lower, by design | Higher |
The “no effect on existing grids” row is the one that makes this an easy decision to trial. Installing the module does not migrate, rewrite, or interfere with anything already built. Legacy grids keep running on UI Components exactly as before. You can adopt it for the next grid you build and never touch the previous ones, which means the evaluation costs one grid rather than a project.
When to reach for it
Internal tooling and operational grids. Reports, queues, sync logs, import results, anything the operations team needs to look at. These are the grids that never get built because the effort outweighs the perceived value, and lowering the cost changes that calculation.
Custom module admin screens. If you are building a module with its own entity, a Hyvä Admin grid gets you a usable management screen quickly.
Teams without deep UI Components expertise. Not every Magento team has someone fluent in the framework. This is a way to ship a competent grid without that specialist.
Diagnostic surfaces during a project. Being able to stand up a grid over a table in an afternoon is genuinely useful during a migration or integration build, when you need visibility into what the system is doing.
When not to
You need a form. Forms are not covered today. If your screen is primarily about editing rather than viewing, this is not the tool yet.
The grid has unusual requirements. Deeply custom rendering, complex interdependent filters, or bespoke JavaScript behaviour will eventually hit the ceiling that the simpler abstraction implies. That ceiling is the price of the simplicity, and it is a fair trade rather than a defect.
You are already fluent and the grid is complex. If your team knows UI Components well and the requirement is genuinely intricate, use the framework built for it. Adopting a simpler tool to avoid a framework you already understand is not a saving.
The honest framing is that this is a sharp tool for the common case, not a replacement for the general one.
The grids most Magento stores are missing
It is worth being concrete about what “internal tooling” means, because the abstract case never persuades anyone.
Almost every Magento store of any size has questions its admin cannot answer. Which orders failed to reach the ERP in the last week, and why. Which products have been sitting with zero stock and no incoming purchase order. Which customer accounts were created but never verified. Which import rows were rejected on the last catalog run. Which quotes have been open past their expiry.
In every case the data exists, usually in a custom table or reachable through a repository the integration already uses. What is missing is a screen. So the answers get produced by a developer running a query on request, which means they get produced late, infrequently, and only when someone thinks to ask.
That pattern is not a tooling failure so much as an economics one. When a grid takes two days, nobody requests it for a question they can work around. When it takes an hour, the calculation changes and the operations team stops depending on a developer to see their own data.
This is the strongest argument for the module and it has nothing to do with elegance. It is that lowering the cost of a screen changes which screens exist.
The licence question, briefly
Hyvä Admin is released under OSL 3.0 and is publicly available on GitHub. That means it does not carry the commercial considerations attached to Hyvä’s paid products, and it does not require a Hyvä theme licence or any Hyvä theme at all.
Worth noting for teams that keep a dependency register: OSL 3.0 is the same licence that covers Hyvä’s supporting theme modules, and it is a well-understood licence in the Magento ecosystem, being the one Magento Open Source itself has used. It is not a bespoke or restrictive arrangement.
Fitting it into a project
The natural moment to introduce this is during a build where you are already adding admin functionality, rather than as a standalone initiative. Two contexts where it earns its place:
During an integration project. ERP, OMS, and PIM integrations generate operational data that somebody needs to see: sync queues, failed records, mapping tables. Those grids are exactly the kind that get deferred indefinitely. We covered the wider architecture in Magento B2B integration patterns for ERP, CRM, and POS, and the observability layer is consistently the part that gets cut and then missed.
During a frontend migration. A Hyvä storefront project is not an admin project, but teams often discover during one that the operations team lacks visibility into something. Having a low-cost way to add a grid means that request can be satisfied rather than added to a backlog. If you are planning that work, our guide to what Hyvä theme development actually involves covers the frontend side.
One practical caution. Because grids are cheap to add, they proliferate. Treat them with the same review discipline as any other code, and periodically remove the ones nobody opens. A dozen abandoned admin grids is its own kind of debt.
How Bemeir helps
Bemeir is a Brooklyn ecommerce agency and the USA’s first official Hyvä Gold Partner, with a direct line to the Hyvä team since the project started. We use the parts of the Hyvä ecosystem that fit a problem, and admin tooling is one where the simpler option is usually correct.
Our Magento and Adobe Commerce development practice covers custom module work, admin tooling, and the integration observability that operations teams actually need, and our Hyvä development services cover the storefront side. We also build on Shopify and Shopify Plus, Shopware, and BigCommerce, and the systems your admin screens report on often come through our technology partner ecosystem.
More about the team is on the about Bemeir page, or start a conversation from the Bemeir homepage.
Frequently asked questions
Is Hyvä Admin part of the Hyvä theme?
No. Hyvä Admin is a separate Magento 2 module that works in the adminhtml area, and it does not require the Hyvä storefront theme or any Hyvä theme licence. The naming causes regular confusion, but a store running the standard Luma frontend can use Hyvä Admin for its admin grids without any other Hyvä product.
Does Hyvä Admin support forms as well as grids?
Not currently. The documentation states that the module offers a new way to create admin grids and that form creation will be supported in future. The repository description mentions grids and forms as the aim, which is where the confusion comes from. If your requirement is primarily an editing screen rather than a listing, plan around UI Components for now.
Will installing Hyvä Admin break my existing admin grids?
No. The documentation is explicit that existing grids and forms are not affected by installing the module and remain unchanged. Adoption is per-grid, so you can build the next one with Hyvä Admin and leave every previous grid on UI Components indefinitely. That makes trialling it a low-risk decision.
What licence is Hyvä Admin under, and is it free?
It is released under the Open Software License 3.0 and is publicly available on GitHub, with copyright held by Hyvä Themes. It carries none of the commercial licensing attached to Hyvä’s paid products. OSL 3.0 is well established in the Magento ecosystem, so it rarely raises questions in a dependency review.
How do you declare a grid in Hyvä Admin?
Two files. Layout XML containing an <update handle="hyva_admin_grid"/> declaration and a reference to the Hyva\Admin\Block\Adminhtml\HyvaGrid block, plus a grid configuration XML file in your module’s view/adminhtml/hyva-grid/ directory that specifies the data source. That source can be an existing repository method or a custom provider. By default every field on the record becomes a column, which you narrow with an inclusion or exclusion list.
