Keep orders from multiple online stores separate using a fixed workspace identity that is checked again on receipt, storage, searching, workflow selection and every external action. A unique order number is not enough: two stores can both have order 10047, use the same customer email address or write to the same ERP.
The error often happens after the webhook
Many teams check which store a message comes from at an integration’s entry point. After that, the store context becomes implicit: a background task contains only the order number, a search screen searches all stores or a retry uses the default configuration. That is precisely where a valid order can become linked to the wrong configuration.
Safe separation has to hold throughout the chain. The workspace belongs with the received event, local order, selected workflow, provider credentials, service action and audit entry. Every query and background task uses that key. A mismatch is not “cleverly” resolved by taking the first order found; processing stops and the item is set aside.
Four layers to check
- Entry point. Link the signature, endpoint and store ID to one permitted workspace.
- Data. Store the store and workspace context alongside the external order number and use composite unique keys.
- Execution. Include the workspace in every job and load providers only from that context.
- Operation. Scope search results, actions, exports and AI tools to the active workspace and authorised user.
These four layers make Connect suitable as a shared integration layer without “shared” meaning “mixed together”. The same applies to agents: order context in customer service is only reliable when the order’s brand and sales channel are clear.
Fictional example: the same number, a different customer
Fictional example: the Buitenblik group manages a consumer store and a business parts store. Both WooCommerce installations have order 8451. A service agent searches for the number from the business workspace. The system finds one order there and shows only that customer. The consumer order is not shown as a second suggestion, even though it technically exists on the same platform.
Later, a delayed background task from the consumer store tries to use the business store’s AFAS configuration. The workspace check detects that the event, order and provider setting do not match. The task is quarantined with a technical reason, and nothing is written externally. This example is fictional, but illustrates why stopping when checks fail matters more than attempting to select the “probably correct” configuration automatically.
Tenant-boundary acceptance checklist
| Test | Expected outcome |
|---|---|
| The same order number in two stores | Each workspace shows exactly one order of its own |
| The same customer email address across two brands | No unsolicited merging of profiles |
| Job with the wrong workspace | Stop and record an audit alert; no provider call |
| User switches workspace | Recheck authorisation and scope the data |
| AI enquiry mentions an order number from another workspace | Do not disclose its existence or customer details |
Run these tests beyond the interface. Test imports, scheduled tasks, retries, exports and support tools too. Pay attention to composite database indexes and cache keys; a cache based only on order number can undermine an otherwise correct design. Also define whether a central service agent may deliberately combine several workspaces, and make that permission explicit.
Review notifications and exports from the recipient’s perspective too. An email saying only “order 8451 failed” can still lead a shared administration team to act in the wrong store. Include the brand, store and workspace in task labels, deep links and audit entries without showing more personal data than necessary. Every deep link must recheck authorisation when opened; a correctly formed URL path is not access control. Clear old search results, browser state and temporary selections when switching workspace. This protects data and prevents the everyday operating mistake of a well-intentioned agent performing the right action in the wrong store.
Schedule a negative authorisation test at least annually. Have a tester deliberately submit identifiers from another workspace through search, API, retry and background-task routes. The correct outcome is the same everywhere: no data, no external change and a useful security notification for the administrator. This tests the complete path, rather than just the visible screen.
Want to manage several online stores safely in one operational environment? Have Yindle assess your workspace and order boundaries.