Learning PathModule

Stores and Business Units

Determine how Stores scope a buyer's commercial context and predict how inheritance behaves across a Business Unit hierarchy.

Ask about this Page
Copy for LLM
View as Markdown

After completing this page, you should be able to:

  • Explain how Stores scope the commercial context of a Business Unit.

  • Apply the Store Override Rule to predict store inheritance.

  • Identify which Business Unit data inherits and which is always explicit.

Stores scope the commercial context of a Business Unit: the assortments, prices, and order visibility a buyer is entitled to. How a Division resolves its Stores depends on its storeMode, and getting this wrong is a common and easily missed cause of B2B checkout failures. If you need a refresher on how Stores and Channels scope a project, see the Model your business structure path.
A simple way to hold the relationship: the Business Unit is the buyer, and the Store is the selling channel it buys through. Assigning a Business Unit to a Store connects that buyer account to a selling channel with its own assortment, prices, and inventory. A Business Unit can share a Store with other buyers, so you do not need one Store per buyer; create a separate Store only when a buyer needs a distinct assortment, distinct pricing, or a data boundary of its own.

Store modes

The storeMode field controls where a Business Unit's Stores come from:
  • Explicit: the Business Unit holds its own Stores directly, in its stores array.
  • FromParent: the Business Unit takes its Stores from the nearest ancestor that has Stores set.
A Company is always Explicit, because it has no parent to inherit from. A Division defaults to FromParent, so by default it inherits its parent's Stores. For the field-level definitions, see BusinessUnitStoreMode in the API reference.
When storeMode is Explicit, the unit's resolved Stores appear in stores. When storeMode is FromParent, they appear in inheritedStores instead. The inheritedStores field is eventually consistent, so it may lag briefly after a change higher in the hierarchy.
A buyer's transaction resources (the Cart, Order, Quote, Quote Request, and similar resources scoped to the Business Unit) must stay consistent with the Business Unit's Stores: when the Business Unit has Stores, every one of those resources must belong to one of them; when it has none, those resources must not belong to any Store. For the exact rule, see the stores field of BusinessUnit in the API reference.

The Store override rule

Store inheritance is all-or-nothing. A Division with storeMode: FromParent inherits the full set of Stores from the closest parent that has Stores defined. The moment you set a Division to storeMode: Explicit and give it its own stores, it stops inheriting parent Stores entirely; explicit assignment replaces inheritance rather than adding to it.
This is the Store Override Rule: one explicit Store on a Division overrides all inherited Stores. There is no merging of an explicit Store with inherited ones.
The following update switches the Commercial Division from inheriting its parent's Stores to using its own. Changing storeMode to Explicit and supplying stores overrides inheritance; the Division now sees only the Store you assign. The version in the request must match the Business Unit's current version, because updates use optimistic concurrency control.
POST /{projectKey}/business-units/key=pacific-commercial HTTP/1.1
Content-Type: application/json

{
  "version": 3,
  "actions": [
    {
      "action": "setStoreMode",
      "storeMode": "Explicit",
      "stores": [
        { "typeId": "store", "key": "pacific-commercial-store" }
      ]
    }
  ]
}
In the response, storeMode is now Explicit, the assigned Store appears in stores, and inheritedStores is no longer present, confirming the Division no longer inherits from its parent.
{
  "id": "7c1f9e22-5555-6666-7777-888899990000",
  "version": 4,
  "unitType": "Division",
  "key": "pacific-commercial",
  "storeMode": "Explicit",
  "stores": [
    { "typeId": "store", "key": "pacific-commercial-store" }
  ]
}
Switching a Division back to storeMode: FromParent empties its stores array and resumes inheritance from the closest parent that has Stores.

What inherits and what is always explicit

Store inheritance is only one of several inheritance behaviors in a Business Unit hierarchy. The following matrix summarizes what a Division can inherit and what it must always define for itself.

AspectInherits?Mechanism
StoresConditionallystoreMode: FromParent resolves to the closest parent with Stores (Store Override Rule)
AssociatesConditionallyassociateMode: Explicit or ExplicitAndFromParent
Associate role assignmentsPer assignmentinheritance on each assignment: Enabled or Disabled (default Disabled)
Approval RulesConditionallyapprovalRuleMode: Explicit or ExplicitAndFromParent
Customer Group assignmentsConditionallycustomerGroupAssignments (beta) resolve from the hierarchy
AddressesNeverAlways explicit on each Business Unit
Custom FieldsNeverAlways explicit on each Business Unit

The associate and approval inheritance modes are covered in detail in Module 2 and Module 7. The key point here is the bottom of the table.

Addresses are always explicit per Business Unit. A Division that inherits its Associates and Stores from its parent still requires its own addresses. A newly created Division with no addresses is a common and easily missed cause of B2B checkout failure, because an order cannot be placed without a shipping and billing address on the Business Unit.

Worked example: Pacific Property Group stores

Pacific Property Group is a Company with two Divisions: Residential and Commercial. Residential shares the parent Company's catalog and negotiated prices. Commercial has a separate assortment served from its own Store.

  • Residential keeps the default storeMode: FromParent. It inherits the parent Company's Store, which delivers the shared assortment and pricing, and its inherited Stores appear in inheritedStores.
  • Commercial is set to storeMode: Explicit with its own pacific-commercial-store. By the Store Override Rule, it no longer sees the parent Company's Store at all; only its own.
  • Both divisions are given their own addresses, because addresses never inherit. Without this step, checkout would fail for both divisions even though their Stores are configured correctly.

This configuration gives Residential shared assortment and pricing with minimal setup, while Commercial gets an isolated assortment, and both can complete checkout.

Putting it together: the setup sequence

The worked examples across this module are steps in a single end-to-end setup. Because some steps depend on others, follow this order when you onboard a buyer organization:

  1. Create the Associate Roles the organization needs. The Merchant Center Business Unit flow requires roles to exist before you can add Associates (covered in Module 2).
  2. Create the Company as the top-level Business Unit, with its own Stores.
  3. Create each Division under the Company. Divisions default to storeMode: FromParent and inherit the Company's Stores.
  4. Override Stores per Division only where a Division needs a different assortment, by setting storeMode: Explicit and its own stores (Store Override Rule).
  5. Add addresses to every Business Unit, including each Division. Addresses never inherit, so a Division without its own shipping and billing addresses cannot complete checkout.

Key takeaways

  • storeMode is Explicit (Stores defined on the unit) or FromParent (Stores inherited from the closest parent with Stores).
  • A Company is always Explicit; a Division defaults to FromParent.
  • The Store Override Rule: setting a Division to Explicit with its own Stores overrides all inherited Stores; inheritance is all-or-nothing, never merged.
  • Stores, Associates, role assignments, Approval Rules, and Customer Group assignments can inherit; addresses and Custom Fields never inherit.
  • A Division with no addresses cannot complete checkout, which is a common and easily missed B2B configuration failure.

Test your knowledge