How should cross-border teams design tiered permissions: who should see what?

Two weeks after an operations employee left, the supervisor discovered that three sub-accounts could still log in to the backend, and one of them had changed the payment collection binding twice in the early morning; in another team, the store manager held both store settings and withdrawal permissions, and one mistaken operation withdrew the receivables from two stores into the same card.

The root cause of such incidents is usually not that 'people are unreliable,' but that the permission table only answers 'what role to give them,' and does not answer 'what they can see, what they can change, and where they can move money.' A structure with multiple stores, multiple platforms, and multiple entities amplifies this problem: at the same 'operations supervisor' job level, A may manage three cross-border stores, while B manages the payment collection entity of one local Thai store. Dividing permissions by job level is equivalent to dividing risk by job level.

Below, we redo the permission design by risk radius: first distinguish the three permission layers, then divide roles, and finally use store groups to align platform sub-accounts, ERP, browser environments, and fund permissions into the same matrix.

First break permissions into three layers: see, operate, transfer.

Vaguely writing permissions as 'admin / operations / customer service' does not define boundaries. First break them into three layers based on 'what losses they can cause':

• Data visibility layer:Order details, customer contact information and addresses, true costs and gross margins, ad spend and ROAS, suppliers and purchase prices. This layer mainly causes information leakage and loss of bargaining power, and does not directly move money.
• Operations execution layer:Listing and price changes, shipping and address changes, refunds and reshipments, coupons and campaign sign-ups, customer service replies. Losses have a per-instance cap but can accumulate; one wrong discount can eat up a store's entire monthly gross margin.
• Transfer and entity layer:Payment account binding and changes, withdrawals and payouts, tax and legal representative information, store entity and authorization, advertising payment methods. This layer has no loss cap, and platform-side audit trails trace back to the entity, not the operator.

The grant order for the three layers runs counter to intuition: data visibility can be relaxed to what the position requires, operations execution is narrowed by store group, and the transfer and entity layer always remains a minimal set with added review. Most teams run into trouble because the third layer gets casually granted to people in the second layer.

Assign roles by risk radius, not by job level

“Supervisors see everything, operators see their own stores” immediately breaks down in multi-store teams, because risk radius has nothing to do with job level and everything to do with what the role can touch. Among people at the same job level, one may only be able to edit titles while another can change payment collection.

A sufficient criterion is: if this role makes a misjudgment or is maliciously manipulated, what is the maximum loss? Can that loss be discovered the same day? The answer determines which category they fall into.

• Those who can touch the fund flow and entity information have no loss cap—the person in charge and finance, usually no more than two people, and they do not participate in day-to-day execution.
• Those who can change prices, inventory, campaigns, and shipping have losses measured by a store's monthly gross margin—store managers, whose permissions are bound to the store group and do not cross entities.
• Those who only handle orders and customer conversations have losses measured per order—operations and customer service, with permissions limited to the order layer and no visibility into costs or payment collection.
• Those without a long-term trusted relationship have losses measured by information leakage and account lending—outsourced designers, influencer liaisons, and temporary part-timers are given only narrow, time-limited permissions that are revoked when the task ends.

Minimum visibility set for the four role types

The table below is a starting point for minimum authorization, not the standard answer. Any exception in any cell must be justified and documented in the permission list; otherwise, six months later no one will be able to clearly explain why he can see it.

Store grouping is the first layer of the permissions container

Checking stores individually is barely workable when there are 3 stores, but once there are 8 or 10, mistakes are inevitable: when a new store opens, nobody remembers to configure permissions, so they simply copy the checkboxes from the previous account and copy over scopes that should not have been granted. Bind roles to “groups,” and a new store only needs to be assigned to a group to inherit them automatically.

1. The first layer groups by platform: TikTok Shop, Shopee, Amazon, and independent sites each form their own group. Cross-platform role capabilities are not interchangeable; having one person manage the dashboards of two platforms at the same time is equivalent to mixing two sets of risk standards together.
2. The second layer groups by country or site: Thailand, Vietnam, and Malaysia are separate. The registration materials, payment collection entities, and after-sales rules of local stores differ by country; mixing them in one group will result in “if you can see the profit of a Thailand store, you can also see that of a Vietnam store.” For details on grouping multiple stores in one country, refer toGrouping and Sub-account Mapping for the TikTok Shop Southeast Asia Local Store Matrix.
3. The third layer groups by registration entity: stores under the same business license belong to one group, and stores under different entities are not allowed to appear within the same role scope. Once a role spans entities, during offboarding handover you cannot determine which entities’ materials the person took with them.
4. The fourth layer is marked by risk level: main stores, test stores, and stores pending disposal are separated. Test stores can be given broad permissions to speed things up, while price changes, main image changes, and payment collection changes for main stores must go through review.

Group names should be self-explanatory, for example “TTS-TH-EntityA-Primary”, and avoid names like “Group 1” and “New Group”—after six months, no one will know what they contain, and no one will dare delete them.

Sub-accounts, ERP, and browser environments must be aligned to the same permission matrix

Configuring sub-accounts only in the platform backend is usually bypassed through the three entry points below, and when it is bypassed, the backend logs look completely normal.

• Browser environment ownership:Whichever stores a Profile is bound to, the holder of that environment can log in to any one of them. No matter how cleanly platform sub-accounts are separated, a shared Profile still renders permissions meaningless. For the one-to-one ownership approach between Profiles and stores, seeEnvironment configuration for running multiple TikTok Shops on one computer , or from theMulti-account managementapproach, pick the isolation granularity that suits your own scale.
• ERP store scope and API key:The ERP main account and exposed API keys often carry greater permissions than platform sub-accounts, capable of pulling order and profit data from all stores at once. When creating ERP sub-accounts for operations staff, the store scope must match the platform side; on the freeze list, API keys should be revoked before sub-accounts.
• Shared receiving and payment accounts:When multiple stores share a single receiving account, any role that can access that account can effectively affect all stores.The joint liability risk of several stores sharing a single receiving accountIn it, the first thing exposed is often exactly this kind of overlap.

The verification method is clumsy but effective: take a table where rows are roles and columns are, in order, platform role, visible store group, ERP store scope, browser Profile, API key ownership, receiving and payment permissions. After filling in each role, find where 'All' appears in a row and ask why.

Funds and compliance permissions: no role may close the loop alone.

If the team has only three people and two-person review is not feasible, a fallback alternative is: concentrate fund-related operations in one master account, isolate the master account's login environment separately, and leave a record in the team group chat for each fund operation, clearly stating the time, amount, and destination. This is not a compliance solution, but it can turn 'no one knows' into 'someone saw it.'

Order of permission changes for onboarding, role transfers, and offboarding.

1. On the first day of onboarding, grant only the group and the minimum role, without checking individual stores item by item. Have the new hire handle orders and customer service for one week first, and only add more when it is confirmed that more data is truly needed.
2. At the end of the probation period, add data visibility layers by role, such as cost and advertising spend; open the operational execution layer by store group; do not open the transfer and entity layers.
3. For a role transfer, first remove the old group, then add the new group; the order must not be reversed. Adding first and removing later will leave the account in both groups at the same time for a period, and the logs will not be able to distinguish which identity was used for operations.
4. Within 48 hours before departure, sequentially freeze platform sub-accounts, revoke ERP API keys, reclaim browser Profiles, remove receiving and payment authorizations, remove from ad accounts, and only then change the primary account password. Changing only the primary password is the most common oversight; for the complete project checklist, seePermission checklist for account handover when an operations employee leaves.
5. Sign off on the handover confirmation form item by item, including store groups, data scope, unresolved refunds, and unspent ad budget.

Common anti-patterns and boundary conditions

• Everyone as admin:A 3-person team is most likely to do this for speed, at the cost of having no boundaries around any mistaken action.
• Shared sub-accounts:When two people use one account, logs cannot be attributed, and when something goes wrong, you can only guess.
• Finance sees profit for all stores:That is reasonable in itself, but if the same finance person also has withdrawal permissions, the fund flow has no second gate.
• Outsourcing uses the primary account:The most common form of account lending usually starts with "just send over a few files."
• Offboarding only changes the main password:Sub-accounts, API key, old Profiles, and payment collection authorization are all still active.

Teams of fewer than three people do not need to copy all four role types, but they should keep at least two lines of separation: money operations separate from store settings, and execution accounts separate from the main account. Even with fewer people, it is not advisable to combine the two in the same person, because once combined, there is no mechanism left to detect problems.