Team & roles

Share a workspace with your team: invite by email, give each person a role, and the role decides what they can see and change. An optional access scope narrows which campaigns and mailboxes the role applies to, so a client or contractor can work inside your workspace without seeing the rest of it. The roster and invitations live under Settings > Members; roles and the permission matrix under Settings > Roles & access.

In the Invite teammates box, paste or type addresses into Emails, separated by comma, semicolon, space, or Enter. Each becomes a chip: valid ones grey, malformed ones red so you can remove them first. Pick one or more Roles for the batch (a description on the right says what you are granting), optionally narrow the batch's Access (see access scope), then Send invitations. A restricted invitee is restricted from the moment they join; there is no window in which they see the whole workspace.

SenditCold sends one invitation per address and reports results as "Invited 2 · 1 failed". Invalid addresses are skipped and called out. The chips clear when the batch finishes.

When several trusted dashboards share one backend, invitation emails link back to the dashboard that sent the invitation. Copying an invitation link also keeps that dashboard's hostname. See multi-dashboard configuration.

An invitation works for 48 hours. A self-hosted instance can shorten that, but not lengthen it.

Pending invitations shows the email, role, access, and expiry for each unaccepted invite, with two actions on the right of the row: copy the invite link (to share directly instead of waiting on email) and cancel the invitation. Copying the link again issues a new link, so only the most recently copied link works; the emailed link is unaffected.

An invitation that ran out stays on the list marked Expired, with Resend in place of the copy action. Resend invites the same address again with the same roles and access: the invitation gets a new link and a fresh 48 hours, and every earlier link stops working. Inviting the address again from Invite teammates does the same thing. The list keeps the 50 most recently expired invitations; cancel one to remove it.

On a self-hosted instance

Two things work differently when you run SenditCold yourself.

An invited person creates their account from the invitation link. A self-hosted instance ships with signups closed to the public (DISABLE_REGISTRATION=invite_only), so visiting the sign-up form directly is refused. The invitation link carries the token that permits the signup, which is why the flow works: the invitee opens the link, clicks Create an account, and lands inside your workspace rather than in a new one.

Invitations may not arrive by email. Platform mail defaults to a transport that writes messages to the backend log instead of delivering them, so copying the invite link is the path rather than the fallback. The members page shows an amber notice above the Emails field when the server reports that mail is not delivered, telling you to invite the person and then copy the link from their row under Pending invitations.

Both are covered in accounts and access, along with how to point the instance at a real relay.

Each row shows email, role, access, and join date, with your own row tagged "you". Open the role picker on a row to tick the roles that member holds; a member can hold several, and their effective access is the union. The owner's row is a fixed Owner badge, and your own row is not editable.

To remove someone, hover (or tap) their row and click the remove icon. You cannot remove the owner or yourself. To leave a workspace you own, transfer ownership first.

Transfer ownership

A workspace has exactly one owner. The owner sees a key icon on every other member's row: click it, confirm, and that member becomes the owner. You are asked to sign in again first if you have not done so recently. The new owner must already be a member, so invite them and wait for them to accept before handing over.

The handover takes effect at once. The new owner gets full control, including billing, deleting the workspace and transferring ownership again, and any roles or restricted access they held are cleared. You stay in the workspace as an Admin, and only the new owner can hand ownership back. Mailboxes, campaigns, contacts, warmup, API keys and a link to SenditCold Cloud are untouched: they belong to the workspace, not to its owner.

A member whose account is scheduled for deletion or suspended cannot take ownership. Only the owner can transfer, and the action is not available to API keys.

Removal applies to someone who is signed in right now. Their open dashboard loses the workspace on its next request and its live updates stop, and they are asked to pick another workspace they belong to. Apps they authorized in the workspace are disconnected. Nothing they created is removed with them: mailboxes, contacts, campaigns and API keys belong to the workspace, so revoke their keys under API keys if those should go too. Realtime channels refresh access at least every 30 seconds and before delivering with an expired authorization check, even if a change event is missed. A changed role or a new owner reaches open dashboards' live updates without a reload.

A role says what a member may do. Their access scope says which resources it applies to:

• Full workspace, the default and what every member had before scopes existed.
• Client, which reaches only the campaign folders, campaigns and mailboxes you choose. This is how an agency shares a client's campaigns and inboxes with that client.

Click the Access cell on a member's row to change it, or Access in the invite box to invite someone as a client. In the dialog, choose Client, pick a client role, then pick from three lists:

A campaign is reachable when it sits in at least one granted folder or is granted on its own. Campaign access never includes a mailbox, even the ones the campaign sends from: inbox access is always granted mailbox by mailbox. Under the mailbox picker, Senders of the selected campaigns lists the mailboxes the chosen campaigns and folders send from, to review and add with one click. A restricted member with nothing selected reaches nothing.

Client roles

A restricted member's roles apply only inside their grants, and only as far as these permissions go:

Every other permission is set aside while the scope is restricted: team, billing, settings, API keys, integrations, AI, contacts and mailbox settings never apply to a client, whatever their role. A role lets clients act when Clients can act inside what is shared with them is on in its editor; it is off for every role until you turn it on, so a role a client already holds keeps them read-only until then. Turning it on or off needs every permission the role grants.

The member dialog offers three presets, added to Roles & access as ordinary roles the first time you pick one:

Roles & access also lists any preset the workspace does not have yet, to add in one click, and marks each role a client can fully use.

Inside their grants, a client is held to the resources they were given:

• Replies go into a conversation whose messages all sit in granted mailboxes, sent from a granted mailbox. The client chooses the recipients, as in any reply. Compose outside a conversation is not available to them, and a forward needs the forwarded message's mailbox granted too.
• Inbox changes (labels, read state, filing, snoozes) name messages or conversations in granted mailboxes; a conversation that also sits in another mailbox is refused. Marking a whole folder read is refused. Opening a conversation marks it read only for a client who can act in the inbox.
• Campaign edits reach granted campaigns that send only from granted mailboxes, listed explicitly with no sender tags. A client cannot change a campaign's senders, sender tags, folders, tracking domain, CC and BCC addresses or status, and can set only email, wait, end and path steps. Steps that act on contacts, the CRM or automations stay as your team set them.
• Starting a campaign needs every sender to be a granted mailbox, listed explicitly with no sender tags. Pausing needs nothing more.
• They cannot create, duplicate or delete campaigns, compose new mail, or open a campaign's leads or settings tabs.

A refused write answers 403 member_access_restricted, and a campaign or mailbox outside their grants answers 404.

What a restricted member sees:

• Campaigns: the list, folder counts, each granted campaign's settings, steps and activity feed, and its analytics. The activity feed uses safe messages and selected metadata; mailbox identities and details outside their mailbox grants, raw provider errors and unknown metadata are not returned. Any other campaign answers as not found, including by direct link.
• Analytics: the dashboard and campaign reports, computed only over their campaigns and mailboxes. Filtered campaign counts are recalculated after intersecting the filter with their grants.
• Workspace summary: campaign counts cover their campaigns, contact counts cover distinct contacts in those campaigns, and mailbox counts cover their mailboxes. Today's confirmed campaign sends must belong to both a granted campaign and a granted mailbox. Member counts and AI voice fields are omitted.
• Inbox: the conversations of their mailboxes, with counts and filters to match. Category lists include only categories applied to conversations with messages in accessible mailboxes. Thread labels require an accessible message; unknown and inaccessible threads both answer as not found.
• Live updates for those resources only. They do not appear in the team's presence and do not see who else is online.
• Copy to workspace: unavailable. Nothing shared with them can be copied to another workspace, and nothing can be copied into a workspace where they are restricted.

Everything that cannot yet be narrowed to a scope is unavailable to them, and shows as locked in their sidebar with the reason: contacts, CRM, templates, forms, automations, deliverability, placement tests, settings other than their own profile and security, the AI assistant, and the Slack app. Resource ownership does not bypass access checks for live events or notifications. They are not sent workspace notifications, including queued email or push notifications, and stored workspace notifications are hidden while their membership is restricted or removed. Personal sign-in security notices remain available. An API key a restricted member already holds, and an app they authorized, are held to the same scope, the same routes and the same client role; they cannot create new keys.

An account whose workspace memberships are all restricted cannot create another workspace, regardless of which workspace is selected. Accounts with no memberships or at least one unrestricted membership can still create workspaces subject to the existing limits. Instance administrators are exempt from this restriction. Submitting, listing or cancelling a workspace limit request requires an unrestricted membership in the request's target workspace, not just the currently selected one. These rules apply to hosted and self-hosted instances.

Changing a member's access needs Manage team and a recent sign-in, takes effect on their next request, and applies to their open dashboard and live updates without a reload. Realtime authorization is cached for at most 30 seconds; campaign and mailbox channels close when a refreshed check refuses access or fails. Organization channels refresh grants on relevant change events and on the same bounded timer. You must hold every permission the member's roles grant, the owner always reaches the entire workspace, and you cannot change your own access. Grants on a deleted folder, campaign or mailbox disappear with it.

Existing unrestricted memberships retain workspace-wide access. These protections use the existing member grants and require no new configuration or data migration. Self-hosted operators should update both the backend/consumer and realtime services so API, notification and channel checks all run the updated code.

Roles are workspace data. Every workspace starts with three seeded roles that are ordinary roles in every respect: rename, recolor, re-permission, or delete them, and add your own. Owner is a membership status, not a role, and there is exactly one per workspace.

Permissions

How the seeded roles map: Viewer holds only the two view permissions plus analytics. Manager adds everything operational (manage campaigns, contacts, sequences, mailboxes, send, unibox, integrations, AI). Admin adds team, settings, billing, and API keys. Owner is Admin plus ownership transfer.

A role also bounds what its members hand to software. An API key a member creates, and an app a member authorizes over OAuth, only gets the API permissions their role covers, and an app's access shrinks with the member's role if it changes later. Members with Manage API keys or Manage settings can see every member's authorized apps under Settings > OAuth apps > Authorized apps and revoke any of them.

On Roles & access, click New role: a name (up to 50 characters, and only "owner" is reserved), a color, and an optional description. Pick a template under Start from to copy a permission bundle, then toggle individual permissions. Assign it from the roster or the invite flow.

Five rules keep this safe:

• Editing a role updates everyone assigned to it immediately. The editor shows how many members are affected before you save.
• You can only grant or take away permissions you hold, so nobody can mint a role stronger than their own. Changing a role's permissions, deleting a role, re-roling a member and removing a member all need every permission involved, old and new; the owner holds them all.
• Ownership transfer can never be part of a custom role.
• Members can hold several roles, and their effective access is the union of all of them. A member left with no roles keeps membership but has no permissions.
• Up to 25 roles per workspace, including the seeded ones.

Custom roles apply everywhere permissions do: API access checks, dashboard visibility, and which realtime events a member receives. For a member with a restricted access scope, a role applies only inside their grants and only as far as client roles allow.