Adobe Commerce Category Permissions let you hide whole categories, product prices, or the add-to-cart button from specific customer groups. You enable the module once, then set per-category rules by website and group. It is the mechanism behind gated B2B catalogs, and on a Hyva storefront it needs one specific caching fix to vary the navigation menu safely.
This is a feature teams reach for when a storefront has to show different things to different buyers: a wholesale tier that sees trade pricing, a logged-out visitor who sees no prices at all, or a restricted product line only approved dealers can order. This guide covers the native configuration, the overlap with B2B Shared Catalog, and the Hyva compatibility work that stops the menu from leaking the wrong categories. For the wider platform picture, see our Magento development services.
What Category Permissions control
Category Permissions is an Adobe Commerce feature. It does not exist in Magento Open Source, where the same outcome requires a third-party extension. When enabled, it gives you three independent controls, set per category and per customer group:
- Allow Browsing Category: whether the group can see the category at all. The alternative is a redirect to a landing page you choose.
- Display Product Prices: whether the group sees prices.
- Allow Adding to Cart: whether the group can purchase.
Those three combine into the common B2B patterns. Show a category with no price and no cart to anonymous visitors, and the full experience to approved wholesale groups. Hide a restricted line entirely from everyone except one group. The controls are granular enough to express most gated-catalog rules without custom code. Adobe’s Category Permissions documentation is the authoritative reference for each option and its scope.
| Visitor type | Browse | See price | Add to cart | Typical use |
|---|---|---|---|---|
| Not logged in | Yes | No | No | Prices behind login |
| Retail group | Yes | Yes | Yes | Standard storefront |
| Wholesale group | Yes | Yes (trade price) | Yes | B2B tier |
| Unapproved group | No, redirect | No | No | Restricted product line |
Enabling and configuring it
Turn the feature on first, then write the rules:
- Go to Stores > Configuration > Catalog > Catalog, expand Category Permissions, set Enable to Yes, and save. It has global scope and is off by default. Refresh the cache when prompted.
- In the same configuration section, set the store-wide defaults: Allow Browsing Category (Specified Customer Groups, or No with a redirect to a Landing Page), Display Product Prices, Allow Adding to Cart, and Disallow Catalog Search for groups like
NOT LOGGED IN. - For category-level rules, open Catalog > Categories, select a category, expand Category Permissions, click New Permission, pick a Website and Customer Group, and set the three controls.
Two inheritance rules matter. An Allow permission on the Root Category cascades to all subcategories and products. And a product that sits in more than one category inherits Allow if any one of its categories grants it, so a restricted item still shows if it is also filed under an open category. That second rule is a frequent source of “why is this product still visible” tickets.
Because browsing permission affects the breadcrumb trail too, a parent category set to Deny drops out of the breadcrumbs on its child pages. Plan the category tree with that in mind.
How Shared Catalog changes the picture
If you run Adobe Commerce B2B, Shared Catalog sits on top of the same underlying permissions module. The important behavior: when Shared Catalog is enabled, it takes over, and the manual per-category group permission settings are ignored. Shared Catalog then fully controls which categories and products each company account sees, along with custom pricing, as Adobe’s Shared Catalog documentation describes.
So the decision is which mechanism owns visibility:
- Category Permissions for group-based gating without full B2B: hide prices from anonymous visitors, restrict a line to one group.
- Shared Catalog for company-account B2B, where catalog scope and price lists are managed per shared catalog.
They are not meant to run as two independent systems on the same store. Our guide to wholesale tier pricing and shared catalog price lists covers the Shared Catalog side in depth, and the broader Adobe Commerce B2B on Hyva compatibility guide maps which B2B features need extra Hyva work.
The Hyva navigation-cache problem
Here is the part teams miss until the menu misbehaves. Category Permissions has to vary the navigation menu by customer group, because the menu itself must only list categories the current group can browse. The base module does this by adding the customer group ID to the cache key of the top navigation block, through a plugin on the standard Magento top-menu block class.
Hyva does not use that block class. Hyva’s navigation is implemented in a ViewModel, not the legacy top-menu block, so the base module’s plugin never fires. The result: the menu is not cached per customer group, which means full page cache can serve one group’s menu to another, exposing categories a visitor should not see or hiding ones they should.
The fix, tracked in the Hyva enterprise compatibility tracker, is to recreate that cache-key plugin against Hyva’s generic template class and match the topmenu_generic block name, so the group ID enters the cache key the Hyva way. The tracker is explicit that you should not simply switch Hyva back to the default block class, because that creates duplicate cache identities and other side effects. A related item handles hiding the search box and advanced search link through layout XML when a group cannot access any categories.
This is exactly the kind of enterprise-module-to-Hyva adaptation our Hyva development services handle on B2B migrations. It is also a reminder that full page cache correctness, not just speed, is at stake: our guide to Magento full page cache and Varnish on Hyva explains why cache keys that fail to vary are a security problem, not only a performance one.
Reindex and GraphQL enforcement
Category Permissions is index-backed. When you enable the feature or change rules, the permissions have to be reindexed before the storefront reflects them, so a change that looks ignored is often just a stale index. Keep the relevant indexers healthy and reindex after bulk permission edits, the same discipline any catalog-scale change needs.
The enforcement matters for Hyva specifically. Hyva fetches a fair amount of data client-side over GraphQL, so permissions cannot be a CSS-only hide on the frontend. They have to be enforced server-side, in the category and product resolvers, so a restricted category or price never appears in the GraphQL response in the first place. A gating approach that only hides elements with CSS is trivially bypassed by reading the network response, which is why the native, server-enforced module is the right foundation rather than a frontend-only trick. If you build custom storefront components that call GraphQL directly, confirm they respect the same permissions the server applies.
Testing it properly
Catalog permission bugs are quiet. The store looks fine to you because you are logged in as admin or as one group. Test like this:
- Log in as a customer in each group, and as a guest, and confirm the menu, prices, and cart buttons match the rules.
- Hard-refresh with full page cache enabled, because the bug only appears once a page is cached against one group and served to another.
- Check the breadcrumb trail on restricted child categories.
- Confirm search does not surface products the group cannot see.
If any of those leak across groups, the cache key is not varying, and the Hyva plugin fix above is where to look.
Gating catalogs on other platforms
Group-gated catalogs are a classic B2B requirement, and platforms handle them very differently:
- On Adobe Commerce, Category Permissions and Shared Catalog are native, with deep per-category and per-company control.
- Teams on Shopify development use B2B catalogs and company-location rules, which are simpler but less granular at the category level.
- BigCommerce development and Shopware development each have their own customer-group and catalog-visibility models, with varying depth.
If your gating rules are complex, with many product lines restricted to different approved groups, Adobe Commerce gives you the most expressive native controls. The trade is that you have to get the Hyva caching right. The team at Bemeir builds these B2B catalogs on Hyva, and our technology partners cover the ERP and pricing integrations that usually sit behind them.
FAQ
Does Magento Open Source have catalog permissions?
No. Category Permissions is an Adobe Commerce feature. On Magento Open Source you need a third-party extension to hide categories, prices, or the add-to-cart button by customer group. Confirm the extension supports your Hyva version, because the storefront rendering and caching are where most break.
How do I hide prices from guests in Adobe Commerce?
Enable Category Permissions under Stores > Configuration > Catalog > Catalog, then set Display Product Prices to apply only to specified customer groups, leaving the NOT LOGGED IN group without prices. You can also disallow add-to-cart and catalog search for that group so guests see a browse-only catalog.
What happens to category permissions when Shared Catalog is on?
When Adobe Commerce B2B Shared Catalog is enabled, it overrides the manual per-category permission settings, which are then ignored. Shared Catalog fully controls category and product visibility and pricing per company account. Use one mechanism or the other, not both, for the same visibility rules.
Why does my Hyva menu show the wrong categories to some customers?
The base Category Permissions module varies the menu cache by customer group through a plugin on the legacy top-menu block, which Hyva does not use because its navigation is a ViewModel. Without a Hyva-specific plugin on the topmenu_generic block, the menu is not cached per group and full page cache can serve the wrong menu.
Do category permissions slow down the storefront?
They add customer-group variation to cached blocks, which increases cache entries but, when the keys vary correctly, does not meaningfully slow a page. The real risk is a misconfigured cache key that either leaks content across groups or multiplies cache identities, which is why the Hyva plugin has to be implemented carefully.
Build gated catalogs that cache correctly
Catalog permissions are powerful and unforgiving on Hyva: the rules are easy to set, and easy to undermine with a cache key that does not vary by group. Bemeir is the USA’s first Hyva Gold Partner and a B2B-focused Adobe Commerce shop. Learn more about Bemeir and how we build gated, cached-correct catalogs for wholesale and distribution storefronts.
