Multi-seat role permissions in client-isolated agency workspaces
Agencies do not fail at outbound because they hire one more SDR. They fail when the wrong seat can edit Client A's voice brief, pause Client B's domain, or approve a send that should have stayed in review. Isolation without roles is theater. Roles without isolation leak the next client's list into yesterday's export.
GTM is built around client-isolated workspaces with email and LinkedIn identities, send windows, domain limits, and a compliance gate that stays on. Multi-seat permissions are how that architecture survives a real agency roster: account leads, copy leads, junior operators, client stakeholders, and automated agents that should never inherit admin rights.
Tenant-scoped roles beat global titles
Oso's multi-tenant RBAC guidance is blunt. A contributor in one company must not touch another company's data even when the role name matches. Roles have to be scoped to a tenant ID at the application layer and at authorization time. Descope's B2B SaaS writeup makes the same point: one human often holds different roles across organizations, and runtime evaluation has to respect that.
For agencies, the tenant is the client workspace. "Agency Admin" is not a free pass into every client's suppression list. "Creator" on Client A does not imply "Creator" on Client B. If your tool only offers account-wide roles, you will invent spreadsheets to paper over the gap, and someone will paste the wrong CSV.
Advox's workspace model for agencies lists a practical ladder: Admin, Manager, Creator, Reviewer, Client. You do not need those exact names. You need least privilege that maps to outbound risk.
A role map that matches outbound risk
Start with five seats. Adjust names to your org chart.
Workspace owner. Connects domains and LinkedIn identities, sets send windows and domain limits, manages funding and credit splits, invites seats, exports audit evidence. Rare. Usually the account lead plus one backup.
Campaign operator. Builds sequences, edits entry rules, manages queues, can pause sends inside that workspace. Cannot reconnect identity credentials or change billing.
Copy / voice editor. Edits voice briefs, claim libraries, and approved proof points. Can open drafts for QA. Cannot publish unsupervised sends unless the workspace is explicitly in supervised mode with that seat named as reviewer.
Reply owner. Sees the shared inbox for that client, owns positive and objection threads, books or hands off calendar. Cannot change sequence structure or domain settings.
Client viewer (optional). Read-only into their own workspace: campaign status, booked conversations, suppression counts. Never cross-client. Never raw prospect export by default.
Zylos' multi-tenant security patterns add one more identity you should not forget: the agent. Agents need machine identity, tenant membership, and tool scopes. An AI send agent that inherits the workspace owner's keys is how quiet over-permission becomes a client incident.
Permissions that matter more than the org chart label
Role names look tidy. Capability lists prevent incidents.
Per client workspace, decide who can:
- Connect or rotate email domains and LinkedIn identities
- Change send windows, daily caps, and warming schedules
- Edit voice briefs and claim libraries
- Force a draft past human QA
- Pause or resume campaigns
- Export prospect lists and reply transcripts
- Edit suppression and CRM sync rules
- Invite new seats into that workspace only
- Impersonate or preview as the client viewer
Anything that can burn reputation or invent a claim should require a higher seat or dual control. Anything that only reads status can sit lower.
Cross-client seats without cross-client data
Account directors need a portfolio view. That is not the same as a shared database. Portfolio dashboards should aggregate counts and health (sends, bounce rate, positives waiting, booked conversations) without letting one click dump Client C's list into a Client D workspace.
When a seat leaves the agency, revoke per workspace, not "disable SSO someday." Instant revoke is a feature buyers ask for because contractor churn is normal in agency life.
How this fits GTM's motion
Find, qualify, write, send, reply, book only stays safe when each stage has a named seat and a hard boundary. The compliance gate still blocks sends without a verdict and an unsubscribe URL. Roles decide who can change the inputs that gate evaluates. Client isolation decides which client's inputs are even visible.
If you are evaluating outbound platforms for multi-client work, ask for a permission matrix scoped per workspace, not a single admin toggle. Then ask whether agents are identities with scopes or silent superusers.
GTM is built for agencies that need that answer before volume starts. Join the waitlist at https://trygtm.com/waitlist when you want client-isolated workspaces with seats that match how your team actually runs.
Sources
- https://www.osohq.com/learn/rbac-examples
- https://www.descope.com/blog/post/rbac-providers-b2b-saas
- https://www.advox.io/en/platform/workspaces/
- https://zylos.ai/research/2026-02-23-multi-tenant-security-patterns-saas-platforms
- /workspace/trygtm/knowledge/product.md