Team & Permissions

Access is decided by a role made of module-plus-action permissions, and then narrowed further per agent. There is one built-in role - Admin - and everything else you build yourself.

The model#

Every member has exactly one role in the workspace.
A role is a grid: for each module, which actions are allowed.
On top of the role, a member can be denied access to specific agents.
Every API route checks the permission itself, so hiding a menu item isn't what's protecting the data.

Admin#

Admin is the only system role. It has every action on every module and cannot be deleted or demoted - which is what stops a workspace locking itself out. The first person to accept an admin invite activates the workspace and becomes its owner.

There is no Owner or Member role built in

Older RBAC designs shipped a fixed ladder. Splice doesn't: below Admin, you define the roles your team actually needs.

Permission modules#

Module	Covers
Agents	Creating, configuring and deleting agents.
Conversations & Inbox	The inbox: approving and rejecting replies, reassigning threads, merging leads.
Leads	Viewing and editing CRM records.
Knowledge Base	The sources the agent answers from.
Integrations	Connecting mailboxes, WhatsApp, calendar, phone numbers.
Routing Rules	Auto-assignment of inbound conversations.
Team	Inviting, removing and re-roling teammates.
Roles & Permissions	Creating and editing the roles themselves.
Billing & Plans	Credits, invoices and plan changes.
Analytics	Workspace reporting.
Tasks	Creating, assigning and managing tasks.
Campaigns	Building and sending outbound campaigns.
Prospects / Outreach	Prospect search and outreach.

Actions#

Action	Meaning
read	See it.
create	Add new ones.
update	Change existing ones.
delete	Remove them.
assign	Hand work to someone else (tasks).
merge	Combine duplicate records (conversations and leads).
manage	The catch-all. Granting manage implies every other action on that module - use it for the people who own an area.

Not every module offers every action - Analytics, for instance, is read or manage.

Custom roles#

1Go to Workspace → Roles and create a role with a name and description.
2Tick the actions it needs, module by module.
3Save, then assign it to members from the Members list.
4Changing a role updates everyone who has it immediately - there's no re-invite step.

Roles that tend to earn their keep:

Support - conversations and tasks in full, knowledge read-only, nothing else.
Sales - conversations, leads and campaigns, but no integrations or billing.
Analyst - analytics read, everything else off.
Ops - integrations and routing, no access to conversation content.

Least privilege is cheap here

Billing, Integrations and Roles are the three modules where a wrong grant hurts: they let someone spend money, disconnect a live channel, or give themselves everything. Grant those deliberately.

Per-agent access#

Roles are workspace-wide. Agent access narrows them. A member with full conversation permissions can still be blocked from a specific agent's inbox - useful when one agent handles something the whole team shouldn't read.

Access is opt-out: members can use every agent unless you turn one off for them, from the member's row in Members. The block is enforced server-side on the conversation, analytics and playground routes, not just in the UI.

Teams#

Teams group members for routing and ownership - Sales, Support, Onboarding. A team can have a lead, and both conversations and tasks can belong to a team.

A conversation can sit on a team's board with no individual assignee until someone picks it up.
Routing rules can target a team rather than a person.
Team membership is independent of role - a team is about who does the work, a role about what they may do.

Inviting members#

1Go to Workspace → Members and click Invite.
2Enter the email address and pick the role they'll have on arrival.
3Send. They get a link valid for 7 days.
4They accept it with a one-time code, which verifies the address and signs them in at once.
5Pending invites can be revoked before they're used. A used invite can't be reused.

One account, one workspace

This is enforced with a hard error, not a warning: someone who already belongs to another workspace gets a 409 and the invite is left unused. They need a different email address, or to leave their current workspace first.

Practical setup

Two admins, not one - a single admin is a single point of failure.
Build roles around jobs, not seniority. 'Support' is a better role than 'Junior'.
Use per-agent access rather than a whole extra role when the only difference is which inbox someone sees.
Review members after anyone leaves. Removal is immediate, but nobody thinks to do it on the day.

PreviousTasks NextRouting Rules