Shopify location roles: source and destination permissions that keep transfers legal

Days of cover can scream that Store 4 is three days from a stockout while the 3PL is sitting on six weeks of the same SKU. That imbalance is real. The transfer it implies may still be illegal for your business: the 3PL will not ship store replenishment, retail cannot feed ecommerce, or the only surplus lives in a returns cage that must never re-enter sellable stock without a QC path. Cover math answers *how much is short*. Location roles answer *which buildings are allowed to help*.

This guide is the permission graph that every other multi-location playbook assumes. It sits underneath multi-location inventory transfers (what to measure and how to size moves), transfer approval thresholds (who signs off once a path is legal), velocity windows (which demand signal to trust), and inbound PO redistribution timing (when freight landing changes the board). Those posts mention roles as a gate. This one is the design doc: how to name roles, draw allowed edges, and keep humans from inventing forbidden paths in Slack.

A role is an edge permission, not a building nickname

Shopify locations already have names: “East Hub,” “SoHo,” “ShipBob LA.” Those labels help humans navigate admin. They do not encode policy. A **location role** is the set of rules that say what that node is allowed to do in your transfer graph:

• Can it be a **source** (ship units out on an internal transfer)?
• Can it be a **destination** (receive internal transfers)?
• Which **other** locations may it feed or receive from — not “any surplus anywhere”?
• Does it **sell** to customers (DTC, retail POS, wholesale) or only hold / stage stock?
• May it **receive vendor freight** (default PO node), or only internal moves?

If you only tag “warehouse” vs “store,” you still leave the dangerous edges open. The useful artifact is a directed path matrix: rows = source candidates, columns = destination candidates, cells = allow / deny / allow-with-cap. Everything automation or a junior lead proposes must pass through that matrix before cover math is even interesting.

A practical role taxonomy for Shopify merchants

Start with five role types. Most brands need a subset; invent new names only when behavior differs.

1. Ecommerce / regional hub

Usually source **and** destination. Picks DTC (and often wholesale) orders. Feeds retail doors on a replenishment cadence. Receives vendor freight or redistributes after a 3PL lands. Hub cover is the number kit and pack availability usually depends on — see kit inventory sync when components must exist where packs actually ship.

2. Retail door

Often destination-only from hubs. Local velocity sizes inbound replenishment; retail rarely should strip another door to “fix” a stockout unless you explicitly allow store-to-store. Selling location: yes. Default PO receive: usually no (door deliveries are a separate purchasing exception).

3. 3PL / fulfillment partner node

Source for contracted channels only. Many 3PLs will ship DTC and refuse retail replenishment. Some will not accept inbound transfers from your own hubs without a separate SLA. Treat the 3PL as a graph node with hard edges — not as “another warehouse with a different address.”

4. Feeder / staging hub

A building whose job is to receive bulk freight and redistribute within N days. It may sell little or nothing. Surplus here is not “overstock to ignore”; it is inventory waiting for a planned second hop. PO timing posts call this out for receipt-day redistribution — roles make the hop list explicit before the truck arrives.

5. Returns, quarantine, and pop-ups

Returns cages: usually neither a clean source nor destination for sellable transfers until QC posts units back to a sellable location. Quarantine: never auto-source. Pop-ups: short-lived destinations with end-date rules so leftover stock has a forced path home. If these nodes look like normal warehouses in your surplus scan, someone will “helpfully” transfer damaged or unsellable units into a customer-facing door.

Directionality: source, destination, both, or neither

Every Shopify location in your review list gets one of four transfer postures. Ambiguity is how forbidden paths sneak in as one-off exceptions that become habit.

1. Both — typical hubs. Can donate surplus and receive when short.
2. Source-only — rare, but useful for a liquidating overflow building that should empty into hubs and never take stock back.
3. Destination-only — typical retail; sometimes a new door during launch week.
4. Neither — returns / quarantine until a separate process promotes units to a sellable location.

Posture is necessary but not sufficient. “Both” at Hub East and Hub West does not automatically allow East → West if your freight contract only supports hub → retail. Path permissions are pairwise.

Build the path matrix before the first auto-approve

List every sellable and staging location as rows (sources) and columns (destinations). Mark each cell:

• Allow — routine replenishment path; eligible for cover-based recommendations.
• Allow with cap — path exists but freight or labor is expensive; only above a shortage severity or under a weekly unit/dollar cap (approval thresholds).
• Deny — contract, insurance, or ops policy forbids the move. Recommendations must never propose it.
• Exception-only — requires named approver and a written ticket; not in the weekly batch.

Fill the matrix in a working session with warehouse, retail ops, and whoever owns the 3PL relationship. The goal is boring consensus, not clever optimization. Common allow patterns:

• Hub → retail for A-movers on a set cadence.
• 3PL → hub when the partner will ship internal transfers to your warehouse (not to stores).
• Hub → hub for regional rebalance when LTL cost is acceptable.
• Feeder → {hubs, contracted DTC nodes} within N days of PO receipt.

Common deny patterns: 3PL → retail, retail → retail, retail → hub (except end-of-season pullbacks), quarantine → anywhere sellable, pop-up → pop-up.

Feeder hubs: plan the second hop on purpose

Purchasing often receives at one node for cost or contract reasons. Demand lives elsewhere. Without a feeder role, every receipt becomes an argument: leave it, panic-transfer, or wait until Monday’s ritual while cover dies at the pick node.

1. Name the default PO receive location per vendor or category.
2. List the **must-feed** destinations and the SLA (same day, next morning, within 48 hours).
3. Size the first redistribution from feeder cover targets — keep the feeder’s contracted buffer; do not empty it into every door “just in case.”
4. Create Shopify transfers on receipt day so available inventory moves with the system of record, not a side van log.
5. Cancel or rewrite the plan if the vendor slips ETA past the stockout clocks at those destinations (PO redistribution timing).

Feeder roles are why “incoming” is location-specific. A PO tagged to the feeder is cover for the feeder — and only becomes cover for Store 7 after an allowed hop executes.

Contract constraints beat clever cover math

Your 3PL rate card, insurance limits, and retail lease rules are part of the inventory system whether they live in Shopify or not. Encode them as denies so software and humans stop rediscovering them under pressure.

• Partner will ship B2C only → deny 3PL → retail even when retail cover is worse.
• Partner charges punitive fees under a carton minimum → allow-with-cap or batch until the threshold; do not fire twelve-unit drips.
• Retail cannot legally hold certain hazmat / age-restricted SKUs → deny those variants on that destination regardless of cover.
• Returns must clear QC → returns location is neither until units land on a sellable hub.

Kits and packs: roles decide where availability is honest

Checkout-native packs expand into real component SKUs. Pack “available” only means something if the components sit at the locations that fulfill the pack. Role design therefore includes a fulfillment scope question: which locations pick kits?

• If only Hub East picks kits, retail component stock should not inflate pack availability — keep retail out of that calculation unless retail fulfills packs.
• Shared components need cover at the pick node; surplus at a denied donor does not rescue the pack.
• Promo kits amplify the cost of a wrong edge: you will burn ads against a pack that cannot ship from the allowed graph.

Merchants on Better Bundles already get component-level lines at checkout, which makes this measurable. Pair role scope with Inventory sync & stock management so merchandising does not launch kits that depend on stock trapped behind a deny.

Document ownership, then audit the edges

A matrix without an owner decays into folklore. Assign:

• Role owner — usually ops lead; approves matrix edits.
• 3PL liaison — owns partner-facing allow/deny cells.
• Retail ops — owns door destination rules and seasonal pop-ups.
• Review cadence — monthly for steady state; weekly during network changes (new door, new 3PL, peak).

Audit by sampling real transfers and recommendations. For each move that shipped last week, ask: was the path Allow? If it was Exception-only, was the ticket filed? If it was Deny, why did it happen anyway — and who taught the team that exception is fine? Pair this with the explainability habit in inventory health score: humans should argue about a cell in the matrix, not a mystery “the system said so.”

Failure modes when roles are vague

• Emergency 3PL → store vans that violate the rate card and train the team to ignore policy.
• Retail-to-retail “favors” that empty a display minimum and create a second stockout.
• Surplus scans that treat returns as free donor inventory.
• PO receive at a node with no feeder SLA — freight sits while DTC cover dies.
• Automation turned on before the matrix exists — thresholds and floors cannot save a forbidden graph (approval thresholds).
• Kit launches that assume company-wide component totals instead of pick-node cover.

Ship-ready checklist (roles before rules)

1. Inventory every Shopify location that holds sellable or staging stock (include 3PL and pop-ups).
2. Assign role type + transfer posture (source / destination / both / neither).
3. Fill the pairwise path matrix: allow / allow-with-cap / deny / exception-only.
4. Name default PO receive nodes and feeder must-feed lists with SLAs.
5. Define kit/pack fulfillment locations so availability scope matches the graph.
6. Publish the one-pager where warehouse and retail can find it; date the version.
7. Only then layer cover targets, velocity windows, approval thresholds, and automation.

You can maintain this with a shared doc and Shopify’s native transfers today. The checklist is policy work — it does not require a new app install.

What FlowOps will do with roles (in development)

FlowOps is Leger Studio’s multi-location inventory app in development. Product direction includes tagging each Shopify location with role and priority, marking whether it can be a source, destination, or both, and refusing to propose transfers on denied paths — including 3PL vs retail constraints — next to days-of-cover recommendations, rules, approvals, and native Shopify transfers. Pricing is TBD; there is no App Store listing yet.

This post is not an install link and does not claim FlowOps is available today. Until launch, keep the matrix next to your transfer ritual, continue with Shopify admin, and watch the FlowOps app page for updates. For product news when FlowOps or other Leger Studio apps ship, subscribe from the site footer or use the contact page.