# Choose one or multiple WMS instances
URL: https://support.starshipit.com/articles/14700000000061-choose-one-or-multiple-wms-instances
Canonical: https://support.starshipit.com/articles/14700000000061-choose-one-or-multiple-wms-instances
Markdown: https://support.starshipit.com/articles/14700000000061-choose-one-or-multiple-wms-instances.md
Updated: 2026-09-11
> For the complete documentation index, see [llms.txt](https://support.starshipit.com/llms.txt).
> Decide when to share one Starshipit WMS instance, when to use separate instances, and how to configure the WMS instance override.
Use this guide to decide whether your operation should use one shared Starshipit WMS instance or separate WMS instances. It explains how instances relate to physical warehouses, how Starshipit accounts point to an instance, and what to verify before you enable the integration.
## The short answer
Choose one shared WMS instance when the accounts share warehouse processes and can scope each operation with WMS client records or account mappings. Choose separate WMS instances when the operations need complete workspace isolation or have product, inventory, order, user or configuration boundaries that cannot coexist in one instance.
For a 3PL, a shared instance can keep each client's products, inventory, orders and user access scoped through WMS client records while preserving one operator interface. See [Set up WMS for a 3PL](/articles/14700000000032-wms-for-3pls-suggested-setup-guide) for that model.
| Choose one shared WMS instance when | Choose separate WMS instances when |
| --- | --- |
| Several Starshipit child accounts share a stock pool, or a 3PL shares warehouse processes while each client's records remain scoped. | Operations require complete workspace isolation or separate operational ownership. |
| You want one operator interface, product catalogue and operational work queue. | Orders, products and warehouse work must not be visible across operations. |
| The accounts share warehouse processes and configuration. | Different operations use conflicting SKU definitions or settings. |
| A parent account or warehouse team can manage the shared WMS environment. | You need to hide shared configuration or enforce reporting, permissions, account-group or operational-ownership boundaries that client scoping cannot provide. |
:::important
A physical warehouse and a WMS instance are different things. Locations and zones describe the physical layout inside an instance. They do not create separate inventory or account boundaries.
:::
## How warehouses, accounts and instances fit together
A physical warehouse is the place where stock is stored and work is performed. A WMS instance is the logical Starshipit WMS environment that owns its products, inventory, orders, locations, users and warehouse settings.
Use **locations** and **zones** to describe areas within an instance, such as bulk storage, pick faces, packing benches or a separate site area. For a 3PL, use WMS client records and access assignments to scope client-owned records inside a shared instance. Use separate WMS instances when the operation needs a hard boundary that the shared instance cannot provide. The number of buildings, floors or zones does not by itself decide the number of instances.
```mermaid
flowchart TD
accTitle: Decide whether to share or separate WMS instances
A[Start with the operational boundary] --> B{Can one WMS instance
support the shared work
and required boundaries?}
B -->|Yes| C[Use one shared WMS instance]
C --> C1[Locations and zones
model physical areas]
C --> C2[Use client records or account mappings
to scope shared operations]
B -->|No| D[Use separate WMS instances]
D --> D1[Each instance owns its
products, stock, orders and locations]
D --> D2[Keep account routing
and writeback separate]
```
The following patterns are common:
| Operation | WMS structure | How to model it |
| --- | --- | --- |
| One warehouse and one stock pool | One WMS instance | Use the current Starshipit account's WMS instance and create locations and zones for the warehouse layout. |
| One warehouse with several brands or sales channels | One shared WMS instance | Enable WMS for each source account and point each one to the same host account with **WMS instance override**. |
| Multiple warehouses with independent operations and separate ownership | Separate WMS instances | Give each independent warehouse or account group its own WMS instance, locations, users and operational settings. |
| Multiple warehouses deliberately operated as one pooled stock and work environment | One shared WMS instance may be suitable | Confirm the order routing, location naming, permissions and inventory writeback before enablement. |
## How WMS instance override works
When an account uses **Use current account**, its WMS order and shipment events go to the WMS instance owned by that account.
When an account selects another linked account under **WMS instance override**, its events go to the selected account's WMS instance. This lets several Starshipit accounts use one WMS environment. The override changes the WMS destination; it does not merge the Starshipit accounts or remove the originating account from the order.
For a shared instance, repeat the configuration for every Starshipit account that sends orders to that instance. The account that hosts the WMS instance must be configured and ready first.
```mermaid
flowchart LR
accTitle: Starshipit accounts routing order events to WMS instances
A[Starshipit account A
Warehouse A] -->|WMS enabled
Use current account| W1[WMS instance A]
B[Starshipit account B
Same stock pool] -->|WMS enabled
Override to account A| W1
C[Starshipit account C
Independent operation] -->|WMS enabled
Use current account| W2[WMS instance C]
```
:::caution
Do not use zones to separate operations that need independent stock, orders or permissions. Zones organize physical locations within one WMS instance. For a 3PL, use WMS client records and client access assignments for client-scoped records. Choose separate WMS instances when you need a hard operational boundary.
:::
## Before you configure the integration
Make these decisions before you enable WMS:
1. List every Starshipit account that creates orders for the warehouse.
2. Decide which account will host each shared WMS instance.
3. Confirm whether stock, products, orders, warehouse users and reporting should be shared or separate.
4. If you use Shopify or another commerce platform with multiple locations, confirm that each source location maps to the intended Starshipit account and inventory writeback destination. See [Set up Shopify with Starshipit WMS](/articles/14700000000018-set-up-shopify-with-starshipit-wms) for Shopify-specific mapping.
5. Make sure you have administrator access to the Starshipit integration settings and the relevant WMS instance.
Only linked or related Starshipit accounts appear as choices in **WMS instance override**. If the account you need is not listed, check the account hierarchy and permissions before continuing.
## Configure the WMS instance in Starshipit
Configure the setting in each Starshipit account that sends orders to WMS. Leave the override on the current account for a separate instance. Select the same host account in every source account when they should share one instance.
1. In Starshipit, go to **Settings > Integrations**.
2. Select **Starshipit WMS**. If it is not connected, select **Add a new integration**, then choose **Starshipit WMS**.
3. Turn on **Enable sending order events to Starshipit WMS**.
4. Under **WMS instance override**, select one of these options:
- **Use current account** to use this account's WMS instance.
- A linked account to send events to that account's WMS instance.
5. Select **Save**.
1. Go to **Settings > Integrations > Add a new integration**.
2. Select **Starshipit WMS** under *Inventory, Warehouse or Retail Management Platform*.
3. Tick **Enable Sending Order Events ['Order Created', 'Order Shipped'] to the Starshipit WMS**.
4. Under **WMS Instance Override (Optional)**, select the linked account that owns the shared WMS instance. Leave it unselected to use the current account's WMS instance.
5. Select **Save**.
The **Expand bundle items when printing shipments** option is separate from instance selection. Only enable it when your WMS bundle configuration requires component items on shipping documents.
## Verify the setup
Test the routing before importing or fulfilling live orders:
1. Open WMS from the host account and confirm that its products, locations and stock belong to the expected warehouse operation.
2. Create one test order from each Starshipit source account.
3. Confirm that each order appears in the expected WMS instance and, for a shared instance, under the correct source account or client mapping.
4. Release and ship a test order, then confirm that the shipment returns to the correct Starshipit account. If inventory writeback is configured for the source commerce integration, also confirm that the inventory update reaches the intended commerce location.
5. Open the expected WMS instance, then check **System > Process Logs** if an event does not arrive or writeback fails.
## Troubleshooting
| Problem | What to check |
| --- | --- |
| The override account is not available | Confirm that the accounts are linked in Starshipit and that you have access to the relevant integration settings. |
| Orders appear in the wrong WMS instance | Check the WMS setting on the account that created the order. The override must be configured on every source account, not only on the host account. |
| Stock from separate operations is mixed together | Confirm that the source accounts do not point to the same WMS instance unless WMS client or account mappings scope the records correctly. Zones cannot separate account-scoped stock. Use separate instances when the operation requires a complete stock and workspace boundary. |
| A shared warehouse shows the wrong physical area | Review the WMS locations and zones, then confirm that order routing and commerce-location writeback match the physical warehouse layout. |
| A user can see more shared configuration than expected | Review WMS roles and client access. Use separate instances when the operation requires complete workspace isolation. |
## FAQ
Does one physical warehouse always need one WMS instance?
No. A physical warehouse can use one shared instance for a common stock pool or a shared 3PL workspace with client-scoped records. Use separate instances when different operations need complete workspace isolation that shared client and access boundaries cannot provide.
Do multiple physical warehouses always need separate WMS instances?
No. Multiple warehouses can share an instance when you intentionally want a pooled operational view or client-scoped records and have confirmed the location, routing and writeback design. Use separate instances when each warehouse requires its own workspace, users or operational settings.
Can multiple Starshipit accounts share one WMS instance?
Yes. Enable WMS for each account and set **WMS instance override** to the same linked host account. Confirm the source account or client mapping for each account before importing live orders.
Can zones replace separate WMS instances?
No. Zones group physical locations inside one WMS instance. They do not create independent inventory, order or account boundaries.
What should I do if I am setting up a 3PL warehouse?
Start with [Set up WMS for a 3PL](/articles/14700000000032-wms-for-3pls-suggested-setup-guide). It explains how shared WMS clients, source-account mappings and client access work alongside the instance decision.
## Related articles
- [Set up Starshipit WMS](/articles/14700000000002-set-up-starshipit-wms)
- [Set up warehouse locations and work areas](/articles/14700000000033-starshipit-wms-locations-and-warehouse-setup)
- [Understand WMS integrations](/articles/14700000000044-understand-wms-integrations)
- [Transfer stock between warehouses](/articles/14700000000040-inter-warehouse-transfers)