Multi-Catalog Hierarchy

Tulip’s Bulk API supports the ability for retailers to send catalog data for multiple product catalogs within Tulip. Multiple catalogs enable users to view store-specific hierarchies for product browsing and navigation. These hierarchies can seasonal, be based on store location, be based on retail prices versus outlet prices, as well as many other classifications.

The key is that, at any given time, users logged into a specific store see the applicable product catalog. In other words, Tulip will display a single catalog per store.

In cases where a store is displaying a catalog specific to a certain region, the app already shows the specific language descriptions in the local language automatically.

This page describes the specifics required to construct requests for Catalogs, Categories, and Product resource types to ensure that retailers can correctly submit request to create multiple hierarchies and share the products and categories between them where applicable.

Catalogs#

Catalogs themselves never appear in Tulip Apps – they are simply a construct to logically organize category hierarchy. Catalogs do not have names, images, or other attributes associated with them. Catalogs have an internal Tulip ID and a reference number (refnum) which is an ID or name that Client teams associate with them for future reference.

When an associate logs into a specific store:

• Only the specific catalog will be accessible through browsing or searching.
• Only stores mapped to that catalog will appear under the availability tab in the PDP (Product Details Page).

Backward Compatibility#

Every client gets a master catalog that includes every product, category, and top level category mapped into it in order to:

• Maintain backwards compatibility.
• Support clients that do not want to take advantage of multi-catalogs.
• Keep the code as simple as possible.

If a store is not explicitly mapped to a catalog id in a specific catalog ID sent through Tulip’s new Catalogs endpoint, the store will default to this master catalog id.

Categories#

Root Level Categories#

Tulip supports the ability to map root level categories to specific catalogs. These are the topmost categories that are loaded when Assisted selling app is loaded for a specific store associate. Only top-level categories belonging to the catalog that are mapped to the current store containing active products is shown.

Root categories can be shared across multiple catalogs by adding multiple parent catalog ID array when assigning in Bulk API. This sharing does not automatically cascade down to child level categories automatically however.

Level 2 and Deeper Categories#

Tulip currently supports mapping Subcategories that are below root level categories, to only one specific Catalog, through the Bulk API. When browsing the Catalog, only Categories belonging to the Catalog that are mapped to the current Store containing Active Products is shown.

Sharing a common Category across multiple Catalogs is not currently supported; however this is something that would be supported in a future revision of Multi-Catalog features. Until then the category must be sent uniquely in a different request - with a unique category reference ID (External ID) corresponding to the Catalog.

Products#

Tulip supports the ability to map a product to specific catalogs. Only products belonging to the catalog that are mapped to the current store appear when browsing or searching in Tulip Apps.

Variants#

Variants are connected to the parent Product. In the current version of Multi-catalog in Tulip, the individual Variant (item) cannot be tied to a specific Catalog.

If a retailer needs to separate Variants by Catalog, the Variant must be grouped with separate distinct Product parents with a unique Product ID specific to a different catalog.

In other words, say a product called ABC-Purse has variants 1-Var-Blue-Purse and 2-Var-Red-Purse. These actually need to be set up such that the Blue Purse item is available in Retail Catalog, and the Red Purse is an Outlet Catalog item. And they both never appear under that same Catalog. The Client data must send two separate Product Parent records as follows:

• First record for ABC-Purse with 1-Var-Blue-Purse; where ABC-Purse product is connected to Retail Catalog,
• A second record for ABC-Purse with child Variant 2-Var-Red-Purse; where ABC Purse product is connected to Sales Catalog.

Alternative Approach: Another approach in case Client system is not able to split and send Tulip separate product records, is to send Tulip the common parent Product and child Variants, but ensure the Inventory specific to the Store or Zone for each Variant is also sent. So when Tulip app is logged into one regional/zone store, the item not relevant to current region is shown but with 0 inventory.

Future updates: Tulip will release an updated version of Multi-catalog support in an upcoming release that will provide a solution which will allow variants to be mapped individually to respective catalogs/stores while being associated with common shared parent. So ABC-Purse as a single record can have two child Variant (items) each connected to Retail and Outlet catalog respectively. Note also that the Product would need to be shared across the Catalogs through either a shared or unique Categories.

Current clients that migrate to the current release of Multi-catalog and choose to stay with this kind of a parent-child relationship or change it in the future once support for updated relationships is available.

Prices#

Prices will remain tied to the location (store-level, region-level, country-level, or brand-level) as currently implemented. Prices are NOT specified at the catalog level.