Roles & permissions
The Owner, Admin, and Member model that controls what each teammate can see, send, and manage — from billing to per-channel access.
Every member of an org holds one of three roles: Owner, Admin, or Member. Roles set which channels a person can read and send through, which admin functions they can do, and who can make billing decisions. This page covers what each role can and cannot do.
Roles at a glance
Owner — there is exactly one owner per org. The owner is the billing account holder and the only person who can change the subscription tier or adjust seat count. The owner is also the last line of authority on any destructive operation. The current owner can transfer ownership to another admin.
Admin — full operational authority within the org. Admins can invite and remove members, change roles (they cannot elevate anyone to owner), manage channels, and share contacts. They cannot touch billing.
Member — a standard teammate. Members see only the channels an owner or admin has explicitly granted them, and they can do all day-to-day messaging operations on those channels.
Capability matrix
| Capability | Owner | Admin | Member |
|---|---|---|---|
| Read messages on assigned channels | ✓ | ✓ | ✓ |
| Send messages on assigned channels | ✓ | ✓ | ✓ |
| View shared contacts | ✓ | ✓ | ✓ (if granted) |
| Post in shared contact comment threads | ✓ | ✓ | ✓ (if granted) |
| Send from shared contacts | ✓ | ✓ | ✓ (if granted SEND) |
| Hard-delete threads and messages | ✓ | ✓ | — |
| Connect a new channel (email / phone) | ✓ | ✓ | ✓ |
| Remove a channel | ✓ | ✓ | ✓ (a mailbox they connected) |
| Grant / revoke member channel access | ✓ | ✓ | — |
| Invite teammates | ✓ | ✓ | — |
| Remove a teammate | ✓ | ✓ | — |
| Change a member's role | ✓ | ✓ | — |
| Share contacts (promote to org-level) | ✓ | ✓ | ✓ (owner of the contact) |
| Manage shared contact members | ✓ | ✓ | ✓ (if contact owner) |
| Change subscription tier | ✓ | — | — |
| Adjust the seat count | ✓ | — | — |
| View billing state | ✓ | ✓ | ✓ |
| Transfer org ownership | ✓ | — | — |
| Create and configure Agents | ✓ | ✓ | ✓ (if the org enables member access) |
| Toggle whether members can use Agents | ✓ | ✓ | — |
| See the Agents approval queue and get agent notifications | ✓ | ✓ | — |
| Generate a Support access code for your own account | ✓ | ✓ | ✓ |
| Act as any teammate, with no delegation needed | ✓ | — | — |
| Act as a teammate they hold a delegation for | ✓ | ✓ | ✓ |
| Create a delegation between any two teammates | ✓ | — | — |
| Have a member delegated to themselves | ✓ | ✓ | — |
| Turn on / configure the Act as policy | ✓ | — (read-only) | — |
Shared contact permits layer on top of role
For shared contacts, org role gives the floor — Owner or Admin always get Send. But the permit level for each contact (View, Comment, or Send) controls what an individual Member can actually do. See Shared contacts for the full permit table.
Team and conversation shares layer on top too
Two more share surfaces grant access beyond channel assignments, each with its own ladder. A team shared at Can view or higher grants access to the team's conversations. Only the team owner, or an org Owner or Admin, can hand out those levels. You can also share a single conversation by name or by link, at Can view, Can send, or Can manage. A conversation share replies from that conversation's own line, in place. A team share replies from a line the reader owns.
Channel access
Channels are the email accounts and phone numbers your org sends and receives through. Access to a channel is the gate that lets you see threads and send messages on it.
Owner and Admin have implicit access to every channel in the org. They need no configuration — when someone adds a new channel, they can use it immediately.
Members get access to a channel one of two ways. They can connect it themselves: when a member connects a new mailbox or number, that grants them access to it right away. Or an owner or admin can assign the channel to them.
When a member connects a channel that the workspace already has, CommSync refuses the connection. An owner or an admin must assign that channel instead. A member adds a number to a platform account only in two cases. They connected that account, or an owner or an admin assigned it to them.
Until a member has access one of those ways, they cannot see any threads on that channel. They also cannot send through it, or receive real-time notifications for it. When someone revokes access, CommSync hides past threads. It still preserves the member's read state, labels, and notes, so those snap back if the member regains access.
To grant or revoke a member's channel access, go to Settings, then Team, open the member's row, and manage their channel list. The same operation is available under Settings, in Phone numbers, and in Email accounts, from the Access control on each channel. It lists everyone who can use the channel and lets admins toggle members inline. On most phone platforms, an assigned account covers every number on it. The page of each phone platform says when it does not.
A grant includes the history
When you grant a member access to a channel, they see the conversations that are already on it, as well as new messages. A revoke hides those conversations again, and a new grant brings them back.
Authority vs. your inbox
Role and channel access answer whether you can use a channel — that is authority, and it is what this page is about. A separate, personal setting answers a different question. Of the channels you can use, which do you actually want to show up in your inbox? See Channels in your inbox for the full picture. But the short version matters here: an owner or admin who narrows their inbox does not lose access to anything.
They can still send from a hidden channel and open a thread on it from a shared link. They can also manage it in Settings, and find it with All org channels in search. The narrower view only changes what shows up in their own inbox list. Presence is always a subset of authority; it never grants anything that role and channel access did not already allow.
Cross-org channel uniqueness
Each channel value — a phone number or email address — is globally unique across all CommSync orgs. You cannot link a number or address that another workspace has already linked. If you try to add a channel that belongs to another org, CommSync returns a conflict error. The error does not name the other workspace. To use that channel, the other workspace must first remove it, or both teams need to consolidate into one org.
This rule exists to keep message delivery unambiguous: CommSync can only deliver a single inbound SMS to one canonical place. If two orgs share a channel, that guarantee breaks.
How to change a role
Owners and Admins can change any member's role from Settings → Team. To promote a member to Owner, you must transfer the ownership token; this automatically demotes the current owner to Admin. You cannot have two owners simultaneously.
Role changes take effect immediately
When you promote a Member to Admin, it instantly gives them access to all channels in the org. When you demote an Admin to Member, it revokes their implicit channel access. They keep only the channels they have explicit grants for (which can be none). Review their channel grants before you demote them.
Agents access
Owners and Admins always have full access to Agents: they can create agents, attach channels, and review the approval queue. Whether Members can create and configure agents is a single workspace-wide toggle, under Settings, then Team, in AI agents. The toggle does not open the approval queue: only Owners and Admins see it and get the An agent needs you notifications. A Member with the toggle on sees an empty queue. That toggle also controls whether Ask can use your workspace's connected MCP tools on a member's behalf. It is off by default — an Owner or Admin has to turn it on before Members see Agents anywhere in CommSync.
A member attaches an agent only to the lines that they can use. They change an agent only when they can use every line of that agent.
How to act as a teammate
Owners — and anyone who holds a delegation, member or admin — can step into a colleague's account to cover their inbox. That access has full fidelity: it includes that teammate's own narrowed inbox presence, while credentials, billing, and workspace settings stay blocked outright for the duration. Each delegation is either full access (reply and file as them) or view only (read, and nothing else).
You manage delegations in Settings → Delegation. The policy that gates them all is owner-only in Settings → Team, and off by default. It covers whether the capability exists, the session window, and whether it requires a reason. See Act as a teammate for the full walkthrough, the transparency the acted-as teammate gets, and what CommSync blocks while a session is live.
Support access
Anyone — regardless of role — can grant a support engineer at CommSync temporary, revocable access to their own account under Settings, in Support access. This is separate from org roles entirely: it is a personal safety valve for people who need help, not a permission another member grants you.
Generate a code
Choose an access window (15 minutes up to 72 hours) and generate a one-time code. CommSync shows it only once, with a reminder to share it only with CommSync support. You can hold at most 5 active codes at a time. To make another, revoke one.
Support redeems it
The code locks to the first admin who redeems it — nobody else can use the same code afterward.
Revoke any time
If you revoke a grant, that immediately ends any active session that uses it, even if the access window has not expired yet.
Not a substitute for org roles
Support access only ever grants access to your own account for the window you chose. It never changes your role, grants channel access to anyone else, or persists past expiry or revocation. A support session also cannot turn on notifications for its own browser, send a test notification, or change your notification choices.
Further reading
- Team & seats — member invites, role changes, and seat management.
- Billing & plans — tier limits, seat pricing, and proration.
- Shared contacts — the permit model that layers on top of roles for org-shared contacts.
- Agents — autonomy modes, guardrails, and the approval queue.
- Channels in your inbox — the presence layer under channel access.
- Act as a teammate — a step into a colleague's account view.