Organizations, members and roles
An organization is the tenant. Every contact, template, message, form, automation, domain, channel, webhook and API key belongs to exactly one, and nothing crosses between them. Which organization you are looking at is the <id> in the URL and the name at the top of the sidebar.
You can belong to — and own — any number of organizations, but you can create only one yourself. That is why Create organization disappears from the switcher while you own an organization you created; transferring it away brings the button back. Organizations a site admin created for you or handed to you don't count against that limit — the API enforces the same rule.
Roles
Four roles, ranked. Two lines are cut through them, and they answer different questions.
| Role | Can change the organization's data | Can manage the organization |
|---|---|---|
| Owner | yes | yes — plus transfer and delete |
| Admin | yes | yes |
| Member | yes | no |
| Viewer | no | no |
"Manage the organization" means members, invitations, API keys, settings and the Activity page. "Change the data" means contacts, templates, sends — everything the public API exposes.
Viewer
Viewer is the read-only tier. It exists because Member was previously the floor, and a Member may write everything the public API exposes — so there was no way to hand someone the dashboard without also handing them the ability to mail your audience.
No page is hidden from a Viewer. Reading the whole dashboard is the role. A strip above the page explains that the role is read-only, and the controls that would write are simply not offered. A Viewer may still leave the organization — that is the one write they keep.
Hiding a button is not the protection
The controls a Viewer would not be allowed to use are hidden so they are not offered something that would only fail. The rule itself is enforced on the server, on every dashboard write, before the request reaches the API — so a refused write costs no quota and leaves no trace in the activity log.
Who may change whom
An Admin reaches only the tiers below their own: they may invite, remove and re-role Members and Viewers. Any change that grants or removes Admin — at either end — is the Owner's. Ownership itself moves only by transfer and is never invitable.
Members
Settings → Members. The roster, plus pending invitations.
- Invite someone takes an email address. The account does not have to exist yet — the invitation is keyed by address, and shows up on their account page (and in their notification bell) the moment they register.
- Pending invitations lists who was invited, by whom and when, with Revoke.
- Row actions: Make admin / Make member / Make viewer, Remove, and Leave organization on your own row.
Transferring ownership
Transfer ownership on a member's row. The target becomes Owner and you are demoted to Admin — you can no longer transfer ownership or delete the organization, and you cannot undo it yourself.
The confirmation names the target by email address alone, even though the table shows display names elsewhere. Names are not unique; this is an identity check before an irreversible action.
Settings
Settings has three tabs. Every member can reach the page — the Members tab is the roster — while the General tab is gated to Admin and above.
Usage
Your plan and what you have spent against it: messages this month, contacts, automations and automation runs, forms, webhooks, domains, channels, templates, members and API keys.
Crossing a ceiling never corrupts work in flight. An import or a broadcast fan-out that runs out of quota completes with the remainder counted as skipped rather than failing. Owners and admins are emailed when a watched monthly quota — today, automation runs — passes 80% and again when it is reached, once per calendar month rather than once per crossing.
How long data is kept is decided by the plan too. The Messages and Activity pages each carry a notice naming their window; anything older than that is deleted automatically.
General
| Card | What it does |
|---|---|
| Name and description | The name in the switcher and the sidebar; the description is the clamped line under it. |
| Logo | Upload and crop. Shown in the switcher and the sidebar. |
| Branding | Default theme, or a custom background and highlight colour, previewed live before saving. The colours are re-mapped for everyone who opens this organization. |
| Unsubscribe page | The copy of your hosted opt-out page — headline, body, confirmation text, an optional redirect URL, and whether it is enabled at all. Every field falls back to a default, so an organization that never opens this card still has a working page. See Unsubscribes. |
| Plan | Which plan the organization is on. On a self-hosted instance there is no ladder and the card says so. |
| Danger zone | Delete the organization. |
Deleting asks you to type the organization's name and to re-authenticate with your password (or an authenticator code). It cascades: everything the organization owns goes with it.
Announcement banners do not follow your branding
Severity colours on a platform announcement are fixed. A platform-wide notice must not change colour based on whose organization happens to be open.
The system organization
If a site admin has added you to it, one organization in your switcher is badged System. It is the platform's own, and it owns the transactional mail Notifyzr sends about itself — login notices, password changes, registration invites.
It behaves differently in ways you will notice: its name cannot be changed, it has no owner and cannot be deleted from the dashboard, its plan is fixed, and its templates and forms are not editable through any interface. Membership is the one part a site admin can manage, and only as admin or member.
Activity
Activity (Admin and above) is the answer to "who changed what, and when" for this organization. A row is written for every successful change, attributed to the person who made it rather than to the key or the service that carried it — so a change you make in the dashboard shows up once, with your name on it.
Two things are deliberately absent:
- Account-level events — sign-in, two-factor, password and email changes. Those belong to a person, not to any one organization, and you are emailed about them instead.
- The request body. It would carry plaintext API keys, passwords, contact PII and whole uploaded CSVs.
An entry records what was done to which resource, not which individual fields changed. Nothing in the product edits or deletes an entry — they only ever age out of the retention window.