Catalog views and policies in Adobe Commerce Optimizer

You synced your catalog. Products and prices are in Commerce Optimizer. You open the storefront and… everything shows up. Every brand. Every category. Every dealer’s pricing mixed together.

That is the moment most teams realize sync was only half the job.

Catalog views and policies are how you tell Optimizer: “this storefront sells this assortment, at this price, for this audience.” Without them, you have a warehouse full of SKUs and no way to split it by dealer, region, or brand.

This post walks through that setup using Adobe’s official Carvelo Automobile demonstration scenario, plus a second example for merchants syncing from Adobe Commerce via the ACO Connector.

The problem: one catalog, many storefronts

Adobe’s Composable Catalog Data Model (CCDM) exists because of a pattern every multi-channel merchant hits.

Say you run three dealer websites. Today, each dealer might maintain its own catalog copy in a spreadsheet or a separate Magento store view. When you update a price on SKU BRK-001, you update it three times. When you discontinue a product, one dealer site still shows it two weeks later.

CCDM flips that. One unified base catalog. Many catalog views on top, each acting as a “lens” that filters products and pricing for a specific audience.

Adobe documents this with a fictitious company called Carvelo Automobile. I will use Carvelo throughout this post because Adobe’s own tutorials, sample data, and admin walkthrough all use it. You can load the same data into your sandbox and follow along.

Sample data repo: aco-sample-catalog-data-ingestion on GitHub

Example 1: Carvelo Automobile (Adobe’s official demo)

Carvelo is an automobile parts conglomerate. Here is the business structure from Adobe’s admin end-to-end use case:

Three brands (child companies):

• Aurora (electric vehicles)
• Bolt (SUVs)
• Cruz (hybrid)

Three dealers:

• Arkbridge (parent company: West Coast Inc.)
• Kingsbluff (parent company: East Coast Inc.)
• Celport (parent company: East Coast Inc.)

Price books per parent company:

• West Coast Inc.: west_coast_inc and vip_west_coast_inc
• East Coast Inc.: east_coast_inc and vip_east_coast_inc

Carvelo has two goals:

1. Maintain a global view with all SKUs across all three brands
2. Let each dealership run its own storefront with unique SKU visibility and pricing, from a single base catalog (no duplication)

That is exactly what catalog views and policies solve.

When you load the Carvelo sample data, Commerce Optimizer Studio already has catalog views for Arkbridge and Kingsbluff. Your job in the tutorial is to set up Celport, the third dealer.

The four building blocks, explained with Carvelo

Before touching the UI, map the four concepts to Carvelo’s world.

Catalog source = where the raw data lives

A catalog source is the authoritative scope of products, attributes, and categories. Usually a locale like en-US, or data from a PIM/ERP.

In Carvelo, the sample data uses en-US as the catalog source. All brands (Aurora, Bolt, Cruz) and all part categories (brakes, suspension, tires, etc.) live in that one source.

Product uniqueness = SKU + catalog source. SKU BRK-001 in en-US is a distinct record from the same SKU in fr-CA.

Shoppers never see catalog sources directly. They see catalog views.

Catalog view = the dealer’s storefront lens

A catalog view picks a catalog source, attaches policies (filters), and links price books (pricing).

One en-US source. Three different lenses. Three different storefronts.

Policy = the filter rules on that lens

Policies inspect product attributes and decide which SKUs pass through.

Arkbridge’s catalog view uses four policies:

• Brand (TRIGGER, for dropdown filtering)
• Model (TRIGGER)
• West Coast Inc brands (STATIC, always limits to West Coast brands)
• Arkbridge part categories (STATIC, limits to categories Arkbridge is licensed to sell)

Kingsbluff uses the same pattern with East Coast Inc brands and Kingsbluff part categories.

Price book = which prices apply

Each catalog view links to a price book. Celport uses east_coast_inc. Arkbridge uses west_coast_inc. Same SKU, different price book, different price on the storefront.

Price books support up to three nested levels (Fallback → Child → Grandchild). The fallback price book defines currency for the entire hierarchy.

Example 2: Adobe Commerce merchant after ACO Connector sync

Not using Carvelo sample data? If you followed Part 2 of this series on the ACO Connector, Adobe already created some of this for you.

Say your Adobe Commerce instance has:

Your products are in Optimizer. Your price books exist. But your Edge Delivery storefront still needs a catalog view that says:

• Catalog source: default
• Policies: maybe a STATIC policy limiting to category = aftermarket-parts
• Price book: base::<SHA1...> for retail shoppers, or dealer::<SHA1...> for VIP

The connector handles ingestion. Catalog views and policies handle presentation. Same model as Carvelo, different attribute names.

Adobe also notes you can export data for only one store view if multiple store views share the same language, then use that single source for multiple catalog views in Optimizer. Example: export only default (en-US) and create separate catalog views for US retail vs US wholesale, each with different policies and price books.

STATIC policies in action: what Celport can and cannot sell

Carvelo’s commerce manager needs a new storefront for dealer Celport. The licensing agreement says:

• Celport sells Bolt and Cruz brands only (not Aurora)
• Celport sells brakes and suspension parts only (not tires, not engine parts)

Two STATIC policies enforce this.

Policy 1: East Coast Inc Brands (already exists in sample data)

This is a STATIC policy. Always on. Filters the brand attribute to allow only Bolt and Cruz. Aurora products never pass.

Policy 2: Celport Part Categories (you create this)

A product must satisfy both policies to appear on the Celport storefront.

Walk through it with a real SKU from the sample data:

Search for brakes on the Celport storefront: results appear.

Search for tires: zero results. Not because tires do not exist in the catalog. They exist in the en-US source. The Celport catalog view filters them out.

That is the difference between having data synced and having a storefront configured.

TRIGGER policies in action: the Brand dropdown on the storefront

STATIC policies set permanent boundaries. TRIGGER policies handle what the shopper selects on the page.

Carvelo’s Edge Delivery storefront has Brand and Model dropdowns. These map to TRIGGER policies:

• AC-Policy-Brand
• AC-Policy-Model

How it works on the storefront:

1. Shopper lands on Celport. No brand selected. No trigger header sent. STATIC policies still apply (Bolt/Cruz only, brakes/suspension only).
2. Shopper opens the Brand dropdown and selects Bolt. The storefront API sends header AC-Policy-Brand: Bolt. The TRIGGER policy filters to Bolt products within the STATIC boundaries.
3. Shopper selects Cruz. Header changes to AC-Policy-Brand: Cruz. Product list updates.

Transport type for triggers: HTTP_HEADER (currently the only supported type).

STATIC = compliance rules that never turn off. TRIGGER = shopper-driven refinement inside those rules.

Step-by-step: create the Celport Part Categories policy

This follows Adobe’s admin end-to-end use case exactly.

Goal: Celport sells only brake and suspension parts.

1. In Commerce Optimizer Studio, expand Store setup and click Policies
2. Click Create Policy
3. Set Name = Celport Part Categories
4. Click Add Filter
5. Fill in the filter:

Attribute:     part_category
Operator:      IN
Value Source:  STATIC
Value:         brakes        (press Enter after each value)
Value:         suspension    (press Enter)

Attribute:     part_category
Operator:      IN
Value Source:  STATIC
Value:         brakes        (press Enter after each value)
Value:         suspension    (press Enter)

Important from Adobe: each value must be entered separately. Press Enter after each one. Attribute names must exactly match the catalog.

6. Click Save in the filter dialog
7. Click the action menu (…) next to the filter and select Enable
8. Click Save on the policy (if Save is greyed out, click the pencil icon next to “New Policy” to add the name)
9. Go back to the policies list and confirm:

Policy name:   Celport Part Categories
Status:        Enabled (green)
Filter:        part_category IN (brakes, suspension)

Policy name:   Celport Part Categories
Status:        Enabled (green)
Filter:        part_category IN (brakes, suspension)

Step-by-step: create the Celport catalog view

Goal: Wire Celport’s policies, source, and price book into one view.

1. Go to Store setup > Catalog views
2. You should see existing views: Arkbridge, Kingsbluff, All views
3. Click Add catalog view
4. Fill in:

Name:            Celport
Catalog sources: en-US
Policies:        East Coast Inc Brands
                 Celport Part Categories
                 Brand
                 Model
Price book:      east_coast_inc

Name:            Celport
Catalog sources: en-US
Policies:        East Coast Inc Brands
                 Celport Part Categories
                 Brand
                 Model
Price book:      east_coast_inc

Why four policies?

• East Coast Inc Brands (STATIC): limits to Bolt and Cruz
• Celport Part Categories (STATIC): limits to brakes and suspension
• Brand (TRIGGER): powers the Brand dropdown
• Model (TRIGGER): powers the Model dropdown

5. Click Add
6. Click the info icon on the Celport row and copy the View ID. You need this for the storefront config.

Verify:

Name:            Celport
Catalog sources: en-US
Policies:        East Coast Inc Brands
                 Celport Part Categories
                 Brand
                 Model
Price book:      east_coast_inc

Name:            Celport
Catalog sources: en-US
Policies:        East Coast Inc Brands
                 Celport Part Categories
                 Brand
                 Model
Price book:      east_coast_inc

Connect the catalog view to your storefront (config.json)

A catalog view in Optimizer does nothing until your storefront sends the view ID on every API request.

Adobe’s storefront boilerplate uses config.json. Here is the relevant section from the Carvelo tutorial, adapted with placeholders:

{
  "public": {
    "default": {
      "commerce-endpoint": "https://na1-sandbox.api.commerce.adobe.com/{{your-tenant-id}}/graphql",
      "headers": {
        "cs": {
          "ac-view-id": "{{celport-catalog-view-id}}",
          "ac-price-book-id": "east_coast_inc",
          "ac-source-locale": "en-US"
        }
      }
    }
  }
}

{
  "public": {
    "default": {
      "commerce-endpoint": "https://na1-sandbox.api.commerce.adobe.com/{{your-tenant-id}}/graphql",
      "headers": {
        "cs": {
          "ac-view-id": "{{celport-catalog-view-id}}",
          "ac-price-book-id": "east_coast_inc",
          "ac-source-locale": "en-US"
        }
      }
    }
  }
}

What each header does:

To find your tenant ID: look at the Commerce Optimizer Studio URL.

https://experience.adobe.com/#/@your-org/in:YOUR-TENANT-ID/commerce-optimizer-studio/...

https://experience.adobe.com/#/@your-org/in:YOUR-TENANT-ID/commerce-optimizer-studio/...

Change the catalog view ID and price book ID, save config.json, and the local preview at http://localhost:3000 picks up the new lens.

Switch ac-view-id to Kingsbluff’s view ID and search for tires: results appear (Kingsbluff has different category policies). Same base catalog. Different view. Different assortment. No data duplication.

Test it: search for brakes vs tires

After configuring Celport, Adobe’s tutorial asks you to run two searches on http://localhost:3000:

Test 1: Search brakes

Product list page shows brake parts. Click a product. Price displays from the east_coast_inc price book.

Test 2: Search tires

Zero results. Tires exist in the en-US catalog source (Kingsbluff can sell them). Celport’s STATIC policy blocks them.

Test 3: Switch catalog view to Kingsbluff

Update ac-view-id in config.json to Kingsbluff’s view ID. Keep ac-price-book-id as east_coast_inc. Save. Search for tires. Results appear. Prices may differ from Celport because Kingsbluff has different category policies.

That third test is the whole point of CCDM. Swap a UUID in a config file. Different storefront experience. One catalog.

Three more real-world patterns from Adobe docs

Carvelo covers the dealer network scenario. Adobe documents three other patterns in the catalog views architecture overview:

Multi-brand conglomerate

Challenge: One parent company owns multiple brands across countries and languages.

Example setup:

• Catalog sources: en-US, fr-CA, de-DE (one per language)
• Catalog views: BrandA-US-Retail, BrandA-US-Wholesale, BrandB-Canada-Retail
• STATIC policies: brand = BrandA on the BrandA views, brand = BrandB on BrandB views
• Price books: retail vs wholesale per region

One base catalog per locale. Views split by brand and channel.

Automotive parts: 3,000 dealers, same products, different pricing

Challenge: Every dealer sells the same SKUs but at different prices based on their agreement.

Example setup:

• One catalog source: en-US
• 3,000 catalog views: one per dealer (Dealer-1001, Dealer-1002, …)
• STATIC policies per dealer: each limits to the brands and categories that dealer is licensed for
• Price books: one per dealer (dealer_1001, dealer_1002, …) synced from your ERP or Adobe Commerce customer groups

Adobe notes Optimizer supports 30k+ price books on this model. No catalog duplication.

Multi-location retailer

Challenge: Same products, different pricing and assortment per store location.

Example setup:

• Catalog source: en-US
• Catalog views: Store-Texas, Store-California, Store-Seasonal-TX
• STATIC policies: region-specific category rules (e.g. California view excludes products restricted by state law)
• Price books: texas_retail, california_retail, texas_vip
• Catalog layer (optional): seasonal campaign overrides product names/descriptions on Store-Seasonal-TX without touching the base catalog

Use a catalog layer when the change is display-only (seasonal name, promo image). Use a separate catalog source when the change affects search, filtering, or sorting.

Common mistakes (with examples)

Mistake 1: Attribute name typo in policy

You create a filter on part_category but your catalog attribute is partCategory. Result: policy matches zero products. Celport storefront shows nothing.

Fix: attribute names must exactly match the catalog. Check in Data Sync or your ingestion payload.

Mistake 2: Creating catalog view before policies

You create the Celport view but forget to create and enable Celport Part Categories first. The view has nothing to filter categories with.

Fix: policies first, catalog view second. Adobe lists this as a prerequisite.

Mistake 3: Wrong price book on the view

Celport view links to west_coast_inc instead of east_coast_inc. Products appear but prices are wrong for East Coast licensing.

Fix: match the price book to the parent company. Celport belongs to East Coast Inc., so use east_coast_inc.

Mistake 4: Forgetting ac-view-id in config.json

Catalog view exists in Optimizer. Storefront still shows the old view (or everything). You updated policies but not the storefront header.

Fix: copy the View ID from Catalog views and set ac-view-id in config.json.

Mistake 5: Expecting policy changes to need a redeploy

Celport’s licensing now includes tires. You add tires to the Celport Part Categories policy and save. Some teams assume they need to re-sync or redeploy.

You do not. Policy changes are live on the next API request. Search for tires on Celport. Results appear immediately.

Mistake 6: Sandbox Optimizer connected to production Commerce

You configure Celport policies in sandbox but your storefront points at production Optimizer (or vice versa). Catalog views, policies, and search config are isolated per instance.

Fix: sandbox pairs with non-production. Production pairs with production.

What to do next

Once Celport (or your own catalog view) is working:

1. Configure search, facets, synonyms, and recommendations in the Merchandising section, scoped to your catalog view
2. Set up your Commerce Storefront on Edge Delivery Services (Part 4 of this series)

For hands-on practice, load the Carvelo sample data and walk through Adobe’s full tutorial:

• Admin end-to-end use case (Carvelo)
• Ingest sample data video
• Sample data GitHub repo

Official resources

• Admin end-to-end use case: Carvelo Automobile
• Catalog views for Merchandising Services
• Policies
• Catalog sources
• Price books
• Catalog layers
• Policies in CCDM (video)
• Catalog views in CCDM (video)
• Why CCDM exists
• ACO Connector overview

Series navigation:

• Part 1: Adobe Commerce Optimizer overview
• Part 2: ACO Connector catalog sync
• Part 3: Catalog views and policies (this post)
• Part 4 (coming): Commerce Storefront on Edge Delivery Services