Back to app

Organization & Team Permissions

What owners and members can each do, how invites work, and how workspaces stay isolated.

Your workspace (an organization internally) owns everything you create. Signing up creates one and makes you its owner.

Who can do what

ActionOwnerMember
Create and send campaignsYesYes
Import contacts, manage listsYesYes
Create templatesYesYes
Use shared SMTP configsYesYes
Add or edit SMTP configsYesYes
Invite teammatesYesNo
See another user's private templatesNoNo

Deliberately simple

There are two roles, not a permissions matrix. Small teams rarely need more, and every extra role is another way to lock yourself out.

How invites work

  1. 1

    The owner invites an email address

    Team → enter their email → Send invite.

  2. 2

    A signed link is generated

    It carries a cryptographic token and expires after 7 days.

  3. 3

    They accept

    Signing in (or signing up) with that exact address, then confirming.

  4. 4

    They join as a member

    With immediate access to shared configs, templates and lists.

Invites are bound to the address

An invite for sam@acme.com can only be accepted while signed in as sam@acme.com. Forwarding it doesn't let someone else in: you'll see a "wrong account" message.

What's shared and what isn't

  • Shared: contacts, lists, SMTP configs, campaigns, statistics, templates marked shared.
  • Private: templates you mark private: enforced by the database, not just hidden in the UI.

Isolation between workspaces

Every table is protected by row-level security. Requests are filtered by workspace membership inside the database itself, so another workspace cannot read your data even if an application bug leaked an identifier.

Did this help?

Related articles