Favorites

Prev Next

This article describes the buyer-specific product list feature in OrderCentral. It explains what the feature enables, the kinds of buyer experiences it supports, and how Favorite can be used as an example of a list type that is shown automatically for each buyer.

Feature Overview

Buyer-specific product lists let you add a product list area to a page and show content that is specific to the person who is signed in.

Instead of linking the page to one fixed list for all buyers, the page can be configured to use a list type such as Favorite. When the buyer opens the page, OrderCentral can identify the buyer and display the first matching Web Product List for that buyer and type.

This makes it possible to reuse one page across many buyers while still showing buyer-specific list content.

What The Feature Supports

This feature supports these capabilities:

  • Show a buyer-specific Web Product List on a storefront page.
  • Resolve a list by list type instead of requiring one fixed list per page.
  • Use Favorite as a buyer-specific list type.
  • Reuse the same page for different buyers, with each buyer seeing their own matching list.
  • Show the resolved list name and products without creating a separate page per buyer.
  • Support page-level presentation choices such as whether to show footer navigation.

Business Value

This feature is useful when you want to:

  • Give buyers a more personal storefront experience.
  • Reduce the need to maintain separate pages for different users.
  • Support workflows such as favorites, quick reorder, or buyer-specific saved lists.
  • Keep the page design consistent while varying the content by buyer.

How The Feature Works

At a high level, the feature works like this:

  1. A buyer opens a page that includes the buyer-specific list feature.
  2. The page is configured to use a list type such as Favorite.
  3. OrderCentral determines which buyer is signed in.
  4. It finds the first matching Web Product List for that buyer and type.
  5. It displays the resolved list on the page.

For the Favorite example, this means each buyer can see their own Favorite list on the same page.

Example Use Case: Favorite Lists

Favorite is the clearest example of this feature.

You can use it to create pages such as:

  • My Favorites
  • Buyer dashboards
  • Quick reorder pages
  • Account landing pages

In this scenario, the component does not need a fixed record page. Instead, it uses List Type = Favorite and resolves the buyer's matching Web Product List automatically.

How It Is Configured

For customers implementing this feature, the typical setup is:

  1. Add Product Lists - Record View to the page in Experience Builder.
  2. Use the page without record context, or leave Record Id empty.
  3. Set List Type to the buyer-specific list type you want to show, such as Favorite.
  4. Optionally set Hide Footer depending on the page design.
  5. Publish the site.

Implementation Requirements

The feature depends on buyer and list data being set up correctly.

For Favorite, confirm that:

  1. The buyer user is related to the correct buyer record in the site context.
  2. That buyer-related record has at least one Web Product List with Type = Favorite.
  3. Favorite is an active value in the Type field for Web Product List.

If these conditions are not met, the component cannot resolve a matching list for the buyer.

Functional Behavior

When used in buyer-specific mode, the feature behaves as follows:

  • The component shows the first matching list for the buyer and selected type.
  • The component title comes from the resolved Web Product List name.
  • The products shown come from the resolved list.
  • If more than one matching list exists, only one list is shown.
  • If no matching list exists, the component stays empty.

For implementations using the Experience Builder component, a page-level Record Id overrides the List Type setting.

Feature Boundaries

This feature is designed for buyer-specific list resolution by type. It is not intended for every product list scenario.

It is not the right fit when the requirement is:

  • Show one fixed list to every buyer.
  • Show the list from the current record page.
  • Let buyers browse or switch between multiple lists.
  • Display a list that is not related to the current buyer's Contact.

Those scenarios need a different page pattern or a record-driven implementation.

Supported Variations

Favorite is only one example. The same feature can support other buyer-specific list types when:

  • The type is available in the List Type property.
  • Buyers have matching Web Product List records for that type.

This allows the page pattern to stay the same even when the business requirement changes from Favorite to another buyer-specific list type.

Summary

Buyer-specific product lists let you use one storefront page to show each buyer their own list based on list type. Favorite is a standard example: the page identifies the buyer, finds the first matching Favorite Web Product List, and displays it automatically. The feature works best when the requirement is to show one buyer-specific list on a shared page.