Shared Catalogs & Custom Catalogs in Magento 2 — Access, Pricing, Performance

Shared Catalogs & Custom Catalogs in Magento 2 — Access, Pricing, Performance

Core Entities: Shared Catalogs and Customer Groups

At the heart of Magento 2's B2B functionality are Shared Catalogs. A shared catalog is not a distinct collection of products but rather a logical layer that defines product visibility and pricing for specific customer groups. The "public" catalog is the default shared catalog visible to guest users. Custom shared catalogs are created to serve specific B2B customer segments.

The primary entities involved are:

• Shared Catalog (Magento\\SharedCatalog\\Api\\Data\\SharedCatalogInterface): The container for visibility and pricing rules. It is assigned to one or more customer groups.
• Customer Group (Magento\\Customer\\Api\\Data\\GroupInterface): The bridge linking customers to a specific shared catalog. A customer group can only be assigned to one custom shared catalog at a time. If a group is moved from a custom catalog back to the public one, its specific pricing and visibility rules are deactivated.
• Product Assignment: This is the explicit association of products to a shared catalog. Products not assigned to a custom catalog are invisible to the associated customer group.

Backend integration note: When synchronizing customer data from an ERP, the customer group assignment is the critical link. Ensure your integration logic can dynamically assign customers to the correct group based on ERP-defined segments (e.g., by tier, region, or contract).

Visibility Rules: Controlling Product Access

Visibility is managed through a system of category permissions and product assignments. The process is hierarchical. When a shared catalog is created, you first select which categories to include. This is a broad-strokes approach.

• Category Permissions: You can allow or deny entire product categories. If a parent category is denied, all its subcategories and associated products are automatically hidden. This is the first gate of visibility.
• SKU-level Allow/Deny: After setting category permissions, you can refine the product list. You can manually select or deselect individual simple, configurable, or bundle products. This allows for granular control, enabling scenarios like offering a base product line to all B2B tiers but reserving specific SKUs for premium partners.
• Rule Sets: The combination of category and SKU-level rules forms a definitive rule set for that catalog. The system processes these rules during indexing to generate the final product visibility list for each customer group.

UI Pattern Note: For merchants with large catalogs, a "deny by default" strategy is often more manageable. Start by denying all categories, then explicitly allow only the relevant ones for a specific B2B group. This prevents accidental exposure of products as new categories are added to the master catalog.

Interaction with Tier Pricing and Customer-Specific Pricing

Shared catalogs are intrinsically linked to pricing. Once products are assigned to a catalog, you can define custom prices in two ways:

• Tier Pricing (Percentage Discount): You can apply a blanket percentage discount to all products within the shared catalog. This is a quick way to implement tiered pricing (e.g., "Gold Tier gets 10% off all assigned products").
• Custom Pricing (Fixed Price): For more granular control, you can set a fixed custom price for any product within the catalog. This price overrides the base product price and any percentage-based tier pricing applied to the catalog. This is essential for negotiated contract pricing on specific SKUs.

This pricing hierarchy is critical: Custom Fixed Price >Shared Catalog Tier Price > Standard Customer Group/Tier Price > Base Product Price. The most specific rule wins. This layered approach allows architects to design flexible pricing strategies that cater to diverse B2B agreements without creating duplicate products.

Architecture & Scope: Multi-Store and Multi-Website

Shared catalog configurations are defined at the global level but their assignments and pricing can be scoped. Product assignments to a shared catalog are global. However, the custom prices you set within that catalog can be defined at the website level. This allows a single shared catalog (e.g., "European Distributors") to have different pricing for the same products on different websites (e.g., a Euro-priced site vs. a GBP-priced site).

Customer group assignments are also global. A customer group is tied to a single shared catalog across all websites. This architecture simplifies user management but requires careful planning in complex multi-national B2B operations where a single customer account might need different product assortments or pricing by region.

Performance Engineering: Indexing and Caching

The performance of shared catalogs hinges on Magento's indexing and caching mechanisms. Because visibility and pricing rules can be complex, Magento denormalizes this data into lookup tables for fast retrieval on the frontend.

• Indexing (catalogpermissions, sharedcatalog): When you save a shared catalog, Magento triggers a reindex. The key indexers are catalogpermissions_product and sharedcatalog_product_item. These create tables that store the final calculated price and visibility status for each product-customer-group combination. This pre-calculation is vital for preventing performance bottlenecks in category and search result pages.
• Layered Navigation & Search: The catalog permissions index directly influences the data available to Elasticsearch. Products excluded from a shared catalog will not be indexed for that customer group, ensuring they do not appear in search results or layered navigation filters.
• Permission Caching: Magento caches resolved permissions. Any customization that programmatically checks product visibility or pricing should leverage the appropriate repository interfaces (e.g., SharedCatalogRepositoryInterface) to ensure these caches are hit, avoiding direct database queries in frontend requests.

Performance Note: For large B2B sites with tens of thousands of SKUs and hundreds of customer groups, reindexing can be time-consuming. Plan for this during maintenance windows. Bulk updates via API should be followed by a scheduled reindex rather than triggering one on every single change.

APIs, Events, and Integrations

Magento provides robust API coverage for managing shared catalogs, which is essential for ERP and PIM integrations.

• REST/SOAP APIs: Key endpoints include /V1/sharedCatalogs for creating/deleting catalogs, assigning customer groups, and managing product assignments (e.g., POST /V1/sharedCatalogs/{sharedCatalogId}/products). These APIs are the standard method for headless implementations and ERP synchronization.
• Observers: Custom modules can hook into events dispatched during shared catalog operations. For example, shared_catalog_product_assign or controller_action_predispatch_sharedcatalog_sharedcatalog_save can be used to trigger custom workflows, like notifying an external system when a B2B catalog is modified.

ERP Sync Note: When syncing pricing, the logic should first determine the target shared catalog based on customer segment data from the ERP. Then, use the API to apply custom fixed prices to the assigned products within that catalog. This ensures that contract pricing is accurately reflected in Magento.

Deployment Strategy: Rollout, Testing, and KPIs

A successful shared catalog implementation requires a structured rollout and testing plan.

1. Pilot Group: Begin with a small, controlled group of B2B customers. Create a dedicated customer group and shared catalog for them. This minimizes risk and allows for focused feedback.
2. UAT Checklist: User Acceptance Testing should be rigorous. Testers must verify:
   • Correct product visibility after logging in.
   • Accurate pricing (both percentage and fixed).
   • Search results and layered navigation filters only show allowed products.
   • Inability to access denied product pages via direct URL.
   • Correct pricing in the cart and throughout checkout.
3. Performance Baselines: Before and after rollout, measure key performance indicators (KPIs). Monitor server response times for category pages, search results, and add-to-cart actions for users in the test group. Pay close attention to the execution time of the relevant indexers.
4. Phased Rollout: Once the pilot is successful, gradually migrate other B2B customer segments to their respective shared catalogs. Avoid a "big bang" approach, as it can complicate troubleshooting if issues arise.