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.

Warmbly 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.

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. There is no resend button. To give somebody a fresh link, invite the same address again: that replaces the invitation in place with a new token and a reset expiry, and the previously emailed and copied links stop working. Copying the link again also issues a new link, so only the most recently copied link works; the emailed link is unaffected.

On a self-hosted instance

Two things work differently when you run Warmbly 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.

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:

• Entire workspace, the default and what every member had before scopes existed.
• Selected resources, which reaches only the campaign folders, campaigns and mailboxes you choose.

Click the Access cell on a member's row to change it. In the dialog, choose Selected resources, 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.

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.

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 and the same read-only routes; 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, only a role's read permissions take effect.