Members and invitations

An organization has members, and each member holds one of three roles. The role decides what they may do with the audience, the templates and the sending — not what they may see.

The three roles

Role	May do
Owner	Everything, including deleting the organization and managing billing
Administrator	Everything except deleting the organization: audience, templates, campaigns, sequences, settings, members
Member	Read. Sees the organization and its data, changes nothing

There is no per-screen permission. That is deliberate: a role you can read off in one line is a role people actually understand. An organization keeps at least one owner. Sending refusals and scheduling notifications go to the owners and administrators — a member is never the one told a campaign did not leave.

Inviting somebody

You invite by email address. The invitation is a link, sent to that address, and it is valid for 24 hours. Accepting adds them to the organization with the role you picked. The invited person does not need an account beforehand — the link takes them through it.

An expired invitation is not a failure, it is a new invitation. Nothing is broken and nothing needs cleaning up: send a fresh one.

What refuses

Inviting an address that is already a member of this organization. Removing the last owner. Going past the number of members your plan allows — the message says the ceiling and how many seats are taken. A member's role can be changed at any time; the change applies to their next action, not retroactively to what they already did.

What it implies elsewhere

Membership is per organization, not global. The same person can be an owner here and a member somewhere else, and their pending invitations are listed in their own account. An API key is not a member, but it belongs to one. A key is created by a person, carries that person's role inside one organization, and is deleted with their account. So a key acts with the rights of whoever made it — which is a good reason to know who made which. See API keys.