Letting branches, agents and departments each manage their own lists — teams, roles and optional maker-checker

Key takeaways

• A team is data isolation inside one account, not a sub-account, and every team shares the same credit pool and the same bill.
• Back-office members belong to one team, while CRM users can belong to several teams at once.
• There are five roles — Account Admin, Team Admin, Operator, Reviewer and Analyst — and Analyst is read-only.
• Maker-checker is an account-level option that is off by default; once on, Operators submit for review and Reviewers or Team Admins approve.
• Submitting a campaign for review does not consume credits; credits are counted when the approved campaign actually sends.

The two most common complaints about list management turn out to be two sides of the same problem.

One is: “the North district team can see the South district’s customers, and that isn’t acceptable.”

The other is: “last month somebody sent an unfinished offer to the entire database.”

The first is a data isolation problem. The second is an internal control problem. Both are solvable inside a single account — split the data with teams, then add an approval step on top where you need one.

This piece covers how that works, what each of the five roles can do, and when you should and should not turn approvals on.

First, the thing people get wrong: a team is not a sub-account

A team is data isolation inside one account, not a set of separate accounts. Every team shares the same platform, the same credit pool and the same bill. The only thing that differs is who can see what.

That design is deliberate. Give each branch its own account and you end up with five bills, five sets of settings, five credit balances to top up separately — and no consolidated view at head office. Teams invert that: billing and platform settings stay centralised at the top, while data separates below.

The shape is roughly:

One account
├── Account team (Account Admin) —— sees everything, owns billing and platform settings
├── Custom team A (e.g. North branch) —— sees only team A's data
├── Custom team B (e.g. Marketing)   —— sees only team B's data
└── Custom team C (e.g. Agency A)    —— sees only team C's data

Two kinds of “people”, kept separate

This is the second common confusion, and the permission rules below will not make sense until it is cleared up.

A. Platform members — the people who log into the back office

Your staff, managers and agency operators. Invited and managed under Account settings → Permissions → Members.

Each member is assigned one team and one role. Together those decide what they see after logging in, whether they can invite others, and whether they can publish or approve.

B. CRM users — your contact lists

Your contacts, customers and subscribers. Each user record has a Teams tab.

Unlike platform members, a CRM user can belong to several teams at once — a VIP customer shared across regions can sit under both “North” and “VIP programme”. When a user is created, the creator’s own team is applied by default. Lists and search filter automatically by the logged-in user’s team.

One line to remember: back-office members belong to one team; customer records can span several.

The five roles

Role	Which team it can sit in	What it can do
Account Admin	Account team only	The whole account: members, billing, platform settings, domains, and every team’s data
Team Admin	Custom teams only	Manages its own team’s members and users; can publish and approve directly
Operator	Custom teams	Creates and edits. Whether it can publish directly depends on whether approvals are on
Reviewer	Custom teams	Edits, plus approves and publishes. Only exists once approvals are enabled
Analyst	Custom teams	Views performance reports only; cannot change any data

A few rules worth committing to memory:

• The account team can only hold Account Admins. Conversely, custom teams cannot hold Account Admins.
• Billing, platform settings and domains belong to the Account Admin alone. A Team Admin manages people, not money.
• A Team Admin manages its own team’s members but cannot create or delete teams — that is the Account Admin’s job.
• Analyst is a genuine read-only role. It suits anyone who needs the numbers but should not touch the list: owners, finance, outside consultants.

Broadly, user management, acquisition forms and messaging campaigns (Email / SMS / MMS / LINE / WhatsApp) are all available to Team Admin, Operator and Reviewer but not Analyst; reports are visible to all four.

How the isolation works

The intuitive way to understand it is “the world you see after logging in”:

• Account team members see every team’s data. When the account holds several teams, lists carry team labels and the view can be switched to a single team.
• Custom team members see only their own team’s data. Another team’s lists, campaigns and forms simply do not exist for them.

Technically the rule is intersection: every resource carries its own team markers, and a user can access a resource when their team and the resource’s teams overlap. That is also why a CRM user attached to two teams is visible to both.

The resources that carry team markers and get filtered include:

• Acquisition forms and sales funnels
• CRM users, tags, target audiences
• Messaging campaigns (EDM, SMS, MMS, LINE, WhatsApp)
• Form submissions and export files
• Orders

The Hong Kong compliance angle

Isolation is not only administratively convenient — in Hong Kong it connects to two real regulatory lines.

The data protection principles under the Personal Data (Privacy) Ordinance require that personal data be used only for the purpose stated at collection, or a directly related purpose, unless the data subject gives prescribed consent. The moment “customer data collected by the North branch” is picked up by the South branch for a campaign, that line starts to strain. Team isolation turns that principle into a system setting rather than a matter of staff discipline.

The promotional messages themselves fall under the Unsolicited Electronic Messages Ordinance, including the 10-working-day deadline for honouring unsubscribes. See Hong Kong promotional messaging compliance checklist.

Maker-checker: the optional approval flow

This is an account-level option, not a requirement. It is off by default and is switched on by an Account Admin under Permissions → Teams.

Turning it on

Enabling it requires selecting at least one scope to review: acquisition forms or messaging campaigns. You can enable one or both.

Only once it is on does the Reviewer role become assignable. Turning approvals off converts existing Reviewers to Operators automatically — nobody is stranded in a role that no longer exists.

What changes

Scope	Approvals off	Approvals on
Acquisition forms	Operators edit and publish directly	Operators edit and submit for review; Reviewers or Team Admins approve and publish
Messaging campaigns	Operators and Reviewers both edit and publish	Operators edit and submit for review; Reviewers or Team Admins approve and send

Details that matter in practice

• Submitting for review does not consume credits. The system states that sending only happens after approval.
• While a campaign is pending, the operator cannot edit it. That is deliberate — otherwise approval means nothing, because the version the manager approved and the version that goes out could differ.
• A Reviewer can approve or reject. If a campaign was scheduled and the review runs past the scheduled time, the campaign is marked expired.
• It covers every broadcast campaign type: EDM, SMS, MMS, LINE broadcasts and WhatsApp.

Forms under review

When an Operator activates a funnel, the action becomes “submit for review” and the status becomes pending. Approval activates it; rejection returns it to draft.

Who is never blocked

Account Admins and Team Admins can always publish directly. Maker-checker governs the Operator layer.

Four worked scenarios

Scenario A: an insurance agency across three regions

Account team: head office · 2 × Account Admin (whole-account view, billing)
├── North team: 1 × Team Admin, 3 × Operator, 1 × Reviewer
├── Central team: 1 × Team Admin, 2 × Operator
└── South team: 1 × Team Admin, 2 × Operator, 1 × Analyst (reports only)

Each region’s Operators see only their own customers and campaigns. Head office uses the all-teams view for a consolidated picture. With messaging approvals on, Operators build the campaign and submit it; the Reviewer approves before anything sends.

Scenario B: a corporate marketing department — control, but no branches

One custom team, “Marketing”, is enough. Operators own content, a Reviewer approves, a Team Admin handles staffing. Enable approvals on both forms and messaging and you have a complete maker-checker.

You do not need to invent multiple teams just to use maker-checker. A single team runs the approval flow perfectly well.

Scenario C: white-label agencies — many agencies, head office stays out of content

One team per agency. The head office Account Admin handles only billing and platform settings. Each agency’s Team Admin manages its own members and lists.

This scenario deliberately leaves approvals off — agency Operators publish directly, because speed matters more. What head office wants here is isolation, not a gate.

Scenario D: customers shared across departments

One CRM user is tagged into both “North” and “VIP programme”, so permitted people in either team can see them. It suits cross-region VIPs and project collaborations.

This is exactly why CRM users may span teams while back-office members may not.

Creating and deleting teams

Creating (Account Admin only):

1. Go to Account settings → Permissions → Teams
2. Add a team
3. Rename it to something meaningful (North branch, Marketing, Agency A)
4. Go to Members, invite people, and pick a team plus a role

Deleting a team shows an impact preview first — how many members, funnels, campaigns and users are affected. On deletion, resources belonging only to that team are deleted; resources shared with other teams merely lose the association; orders are reassigned to the account team rather than deleted.

FAQ

Do we have to use teams at all?
No. The default account team works fine on its own. Custom teams are only needed once separate business units, branches, departments or agencies each manage their own lists.

Can one employee belong to several teams?
No. A back-office member belongs to one team. CRM users — your customer records — can belong to several.

Who can create a team?
Only an Account Admin. A Team Admin manages its own team’s members but cannot create or delete teams.

Can a Team Admin invite an Account Admin?
No. Account Admins can only exist in the account team.

If approvals are off, do we still assign Reviewers?
No, and the role is not offered. Turning approvals off converts existing Reviewers to Operators.

Can approvals be enabled for just one team?
The approval setting is account-level. But because data is already isolated by team, in practice a team’s own Reviewer or Team Admin reviews that team’s campaigns.

Can content be edited after it is submitted?
Not while it is pending. If it needs changing, the Reviewer rejects it back, the Operator edits, and it is resubmitted.

Does submitting for review deduct credits?
No. Credits are counted when the approved campaign actually sends.

Does deleting a team delete the list?
Only resources belonging solely to that team are deleted; shared resources just lose the association. The impact preview runs before you confirm.

Does each team get its own sending quota?
No. Teams share the account’s credit pool and bill — teams divide visibility, not money. If you need per-unit billing, that is a different requirement and worth discussing separately.