USF Header Record Logic for Multi-Store Customers

This document explains why shared header records are required for multi-store customers using Unified Storefront (USF), and how USF treats those records during import and catalog presentation. It is intended for internal use by Professional Services, Support, Sales Engineering, and Product.

Core Rule

For a multi-store customer to work properly in USF, items must have a shared header record in store 000.

USF relies on that shared header record as the foundational item record for import. Store-specific data can then layer on top of it, such as availability, rates, or quantity by location.

Without the shared 000 header record, USF does not have a supported base item record to import into the storefront catalog.

How USF Handles Header Logic

USF imports item header records from store 000. Store-level visibility and location-specific behavior happen after that import step.

That means:

• The item must first exist as a valid shared header record in 000
• Store-specific records alone are not enough to establish the catalog item in USF
• Individual stores can still have their own availability, pricing, or quantities tied to their store records
• The storefront experience remains one unified catalog built from the shared header layer

What This Means in Practice

A multi-store customer is a fit for USF when:

• They operate a single storefront
• Their core item catalog is built from shared header records
• Store-to-store differences are mainly operational, such as:
  • quantity on hand
  • availability by date
  • pricing/rates
  • fulfillment by location

In this model, the header record is the anchor. The store records support local behavior, but they do not replace the need for the shared item foundation.

Required Data Structure

For supported USF multi-store behavior:

• Each item should have a header/shared record in 000
• Store-specific records may exist for locations like 001, 002, etc.
• Those store-specific records should be understood as extensions of the shared item, not standalone catalog items

What Happens If Header Records Are Missing

If a customer only maintains item records at the store level and does not use shared 000 header records:

• Those items are not imported into USF as expected
• Catalog completeness becomes unreliable
• Store-level configuration cannot compensate for the missing shared header structure

This is not a setup preference. It is a requirement of how USF imports and builds the catalog.

Internal Guidance

When evaluating or onboarding a multi-store customer, confirm early:

• Do their items use shared header records in 000?
• Are store-specific records being used only to support location-level differences?
• Is the intended experience a single unified catalog rather than separate catalog ownership by location?

If the answer to the first question is no, that should be treated as a structural risk to USF fit.

Internal Positioning Statement

Use this internally when explaining the requirement:

“USF multi-store support depends on shared item header records in store 000. USF imports the item from that shared header level first, then applies store-specific availability, rates, and quantities after import. Store-only item records are not sufficient to support the expected catalog behavior in USF.”

TL;DR

• Multi-store customers must use shared 000 header records
• USF imports from the header level first
• Store-specific records support local behavior, but do not replace the header
• Missing 000 header records create unsupported catalog behavior in USF