# Stores and Business Units

[Stores](/api/projects/stores.md) 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](/learning-model-your-business-structure/stores-and-channels/overview.md) 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](/api/projects/business-units.md#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](/api/general-concepts.md#eventual-consistency), 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](/api/projects/business-units.md#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](/api/general-concepts.md#optimistic-concurrency-control).

```http
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.

```json
{
  "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.

| Aspect | Inherits? | Mechanism |
| --- | --- | --- |
| Stores | Conditionally | `storeMode: FromParent` resolves to the closest parent with Stores (Store Override Rule) |
| Associates | Conditionally | `associateMode`: `Explicit` or `ExplicitAndFromParent` |
| Associate role assignments | Per assignment | `inheritance` on each assignment: `Enabled` or `Disabled` (default `Disabled`) |
| Approval Rules | Conditionally | `approvalRuleMode`: `Explicit` or `ExplicitAndFromParent` |
| Customer Group assignments | Conditionally | `customerGroupAssignments` (beta) resolve from the hierarchy |
| **Addresses** | **Never** | Always explicit on each Business Unit |
| **Custom Fields** | **Never** | Always 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.

## Related pages

- [Area overview page with navigation](/learning-model-b2b-commerce.md)
- [Previous page: Business Units: Company and Division](/learning-model-b2b-commerce/model-buyer-organizations/business-units-company-and-division.md)
- [Next page: Learning check](/learning-model-b2b-commerce/model-buyer-organizations/learning-check.md)