At two a.m., a customer service sub-account, while responding to a dispute at Store C, accidentally clicked the inventory edit field, marking 200 units at Store A as 0. The order pools at Stores B and C simultaneously triggered restocking alerts. During the post-incident review, everyone's first reaction was "that colleague wasn't properly trained," but the real problem was: the customer service sub-account should never have seen the inventory edit field — the permission boundary had not been drawn down to the field level, and a single misclick cascaded across stores. The core logic behind the configuration method below comes down to one rule:Can a wrong action be rolled back within 15 minutes, loosen what can be rolled back, lock down what can't.
How many stores before you need to split sub-accounts? Three hard criteria
Decision formula: total SKUs × daily average orders × number of active platforms.
- 1–2 stores, SKU ≤ 200, daily orders ≤ 50:A shared primary account with spot-checked operation logs is sufficient; the configuration cost of splitting sub-accounts outweighs the benefit.
- 3–4 stores, 200–2000 SKUs, 50–500 daily orders:You must split roles across four lines, and write permissions for inventory and pricing must be distributed to at least two people.
- 5+ stores, 2000+ SKUs, 500+ daily orders:On top of role splitting, add a data isolation layer (field-level visibility); otherwise, cross-store promotional inventory and pricing conflicts will grow exponentially.
If you're still at the stage where one person manages all stores across multiple browser windows, first cross-referencethe phased task breakdown for multi-store operationsto confirm which stage you're currently in before adjusting permission configurations.
Roles are divided by the "degree of action irreversibility," not by job title
Don't use job titles like "Operations," "Customer Service," or "Warehouse Management" to create roles. The fields in each cell represent every field that sub-account can access — the customer service role in the system isn't "prohibited from editing inventory" but rather "the inventory editing field doesn't exist." For specific field-level permission division, refer toPermission Division and Collaboration for Inventory, Orders, and Customer Service.
| Operations line | Read-only | Editable for this store | Cross-store approval |
|---|---|---|---|
| Inventory (SKU quantity) | View in-stock / in-transit for this store | Adjust this store's safety stock threshold | Cross-store transfer release (supervisor sign-off required) |
| Pricing (selling price / promotional price) | View all-store pricing | Adjust this store's daily selling price (within ±10%) | Promotional pricing, cross-store unified pricing |
| Orders (claim / ship) | View Your Store's Order Pool | Claim Your Store's Orders, Print Shipping Labels | Cross-Store Reassignment, Cancel Shipped Orders |
| Customer Service (Tickets/Reviews) | View Your Store's Tickets | Reply to Your Store's Tickets, View Reviews | Cross-Store Complaint Escalation, Batch Refunds |
Data Isolation Boundaries: Which Fields Are Visible Across Stores and Which Must Be Locked Down
"Isolation" does not mean "completely invisible." Visibility is divided at field granularity:
- SKU master data (barcode, specifications, cost):Global read-only sharing ensures that procurement and finance follow the same reporting standards.
- Promotional inventory and campaign budgets:Locked per store: promotional spend at Store A does not affect available inventory at Store B, even when the same SKU is sold.
- Customer reviews and ticket records:Isolated per store: customer service sub-accounts can only view tickets belonging to their assigned store, preventing cross-store reporting conflicts.
- Operation logs and approval records:Global read-only: supervisors can trace exactly who changed which field at which store and at what time.
Unidirectional flow principle: inventory data flows upward from the warehouse management layer for aggregation and cannot be written back to inventory directly from the order layer; prices flow downward from the costing layer, and operations can only make fine adjustments within defined thresholds without reverse-modifying the costing baseline.
Configuration sequence: from irreversible to rollback-capable, set up completely in one pass with no rework.
Operate in reverse risk order; after each step is completed, immediately execute the designated minimal test action, confirm everything is correct, then proceed to the next step:
- Lock write permissions for price and inventory.Assign the "Edit Own Store" price and inventory fields to the corresponding sub-account, and set all other roles to read-only.Test: Open the inventory editing page with a customer service sub-account and verify that the fields are not visible.
- Switch the order claim scope.Bind each sub-account's order pool to a specific store ID; cross-store reassignment is handled under "Cross-Store Approval."Test: The Store A operations sub-account searches an order number and verifies that only records from its own store are returned.
- Enable customer service ticket ownership.Tickets are auto-assigned by store; customer service sub-accounts default to pulling only their own store's queue.Test: The Store B customer service sub-account logs in and verifies that no Store A tickets appear in the queue.
- Configure data dashboard visibility.Promotional inventory and customer review modules are isolated per store; SKU master data is globally visible.Test: Open the dashboard and verify that promotional inventory figures show only for the current store.
- Enable operation log auditing.Global read-only log fields: operator, timestamp, store, field name, old value, new value.Test: Perform one price change and confirm that all five log columns are present.
- Enable the cross-store approval workflow.Cross-store transfers, unified pricing, and batch refunds must go through approval; the approver must be independent of the executor.Test: Initiate one cross-store transfer and confirm that inventory has not changed prior to approval.
On tool selection, teams with 2–8 stores do not need an ERP;picking the right tier based on inventory scale and daily order volumematters more than piling on features. Before configuring permissions, confirm whether your tool supports field-level role control; if not, switch tools first, then configure.
Three verifications to complete within 72 hours of going live
- Privilege escalation interception:With each sub-account, attempt a cross-store price change (outside that store's scope) and confirm it is blocked by the system or routed to the approval workflow rather than executed directly.
- Inventory Pool Independence:Simulate Store A's inventory for a given SKU dropping to zero. Confirm that the same SKU's inventory pool in Stores B and C is not deducted in tandem, and that the restocking alert fires only for Store A.
- Log Integrity:Spot-check all operation logs over 72 hours. Confirm that "who / when / which store / which field / old value → new value" is complete with no missing entries, and that cross-store approval records include approver signatures.
All three checks must pass for the configuration to be considered closed-loop. If any one fails, roll back to the corresponding step and re-lock. Do not "go live first and patch later.".
Frequently Asked Questions
Is there a limit on the number of sub-accounts? What happens when the team grows to 20 people?
Most SaaS tools cap sub-accounts at 10–30. Once roles exceed 15, it is recommended to introduce a department-level RBAC framework: first group by "Operations / Customer Service / Warehouse Management," then apply four-line authority separation within each group to avoid role explosion. For scale assessment, refer toMulti-Account Store Management Tools and Workflow Breakdown.
Is there a risk-control difference between a shared mailbox and individual sub-accounts?
Yes. A shared mailbox means multiple operators share a single login credential, and platform risk control attributes all those actions to the same signal source; individual sub-accounts each hold their own credentials, so behavioral signals can be distinguished. However, risk-control association is a multi-factor overlay (credentials, network egress, device fingerprint, data behavior); a single factor does not necessarily trigger an account ban. Defer to each platform's account notifications and official policies.
Can a single permission template be reused across Amazon + Shopee + independent stores?
The role-division logic across the four lines is reusable, but field names and approval thresholds must be adjusted per platform: in the Amazon backend it is called Manage Inventory, on Shopee it is called "Batch Modify Inventory", and on independent stores it is the SKU's stock_quantity. First draw the matrix with one unified logic, then map fields platform by platform—do not simply copy and paste.
What is the SLA for revoking permissions on the day an employee leaves?
We recommend completing four steps within 2 hours: the primary-account admin disables the sub-account → check for pending cross-store approval tickets → reassign them via manual work orders → confirm the last entry in the operation log. Any sub-account not revoked within 24 hours is treated as a "ghost account" and must trigger a security audit.
