Roles and permissions explained

Every workspace has four roles. They are deliberately few — most access questions are better answered by a workspace policy than by inventing another role.

The four roles

Owner — full control of the workspace. There is exactly one, and the owner can never be demoted or removed by anybody, including another admin. This is what stops a workspace being locked out of its own account.

Admin — manages members, workspace settings, email configuration, automations and billing. Admins can change and remove other admins.

Member — the everyday working role. Whether members may create, edit and delete records is a workspace policy you control, so "Member" can mean full contributor or read-mostly depending on how you set it.

Viewer — read-only. Viewers never send email under any circumstances, and no policy toggle changes that.

Workspace policies

Rather than adding more roles, several toggles adjust what members specifically may do: whether they can edit records at all, whether they can change their own name, email or job title, whether they can make records they own private, and whether they can verify their own personal sending address.

Admins and owners bypass these policies — they exist to widen or narrow the Member role, not to constrain administrators.

Rules that cannot be overridden

A few constraints are enforced by the platform itself rather than being configurable, because every one of them exists to prevent a way of locking yourself out or quietly escalating privilege:

• The owner cannot be demoted or removed.
• Nobody can promote anyone — including themselves — to owner.
• Nobody can change their own role or status, or remove themselves.
• Members manage their own details through their profile, never through member administration.

Sending permissions

Who may send email from which address is a separate, finer-grained rule layered on top of roles — see Senders and who may use them. In short: viewers never send, admins send from anything active, and members send from their own address or shared ones they have been granted.

Auditability

Every role change, policy change and record mutation is written to the audit log with the person who did it, a timestamp and a field-level diff of what changed. If you need to answer "who gave them access, and when", the answer is there.