Teams, roles and invitations

An organisation owns everything: the apps, the links, the API keys and the billing. People are members of an organisation, and each member has one of three roles.

There is no per-app permission. Somebody who can create links can create them for any app in the organisation. That is a deliberate simplification rather than an omission — a permission model nobody can hold in their head is one that gets worked around, usually by sharing an owner account.

What each role may do

Billing and deleting the organisation are owner-only too. Billing itself is not built yet, so there is nothing to configure; the restriction is in place so that it does not have to be added later.

Why member can make links but not keys

Making a link is day-to-day work for whoever is running a campaign. An API key is a credential that acts on the whole app without a person attached to it. Those are different kinds of thing, and the most common real-world request — “let the marketing team make their own links, but do not give them our keys” — is exactly the line between them.

There is always at least one owner

The person who creates the organisation is its first owner. There can be more than one — that is the intended arrangement for anything other than a single founder, so that being on holiday is not a reason nobody can add a colleague.

The one rule the product enforces is that the last owner cannot be demoted or removed. An organisation with no owner has nobody who can invite anybody, change a role or manage billing, and there is no self-service way back out of that state.

To hand the organisation over, make the other person an owner first, then change your own role. In that order it is allowed, because at no point is there nobody in charge.

Inviting somebody

An owner invites by email address and chooses the role at the same time. The invitation is a single-use link, valid for 7 days.

The person invited does not need an account first. If they already have one, accepting adds the organisation to it; if they do not, they are asked to create one and are added on the way through.

An invitation must be accepted by the address it was sent to. Signing in as somebody else and following the link does not work, and says so plainly rather than failing quietly.

Inviting the same address again withdraws the previous invitation. There is only ever one live link per person per organisation, so an old email forwarded on to somebody else is not a way in.

When an invitation expires

It stops working, and the page says the invitation has expired rather than pretending it never existed. Send another one; there is no limit and no penalty. Pending invitations are listed in the organisation settings, where they can also be revoked before they are used.

Removing somebody

An owner can remove any other member. What that person made — apps, links, keys — belongs to the organisation and stays exactly as it was. Removing somebody ends their access; it does not undo their work, and a link printed on something physical does not stop working because the person who made it has left.

What is recorded

Invitations sent, accepted and revoked, role changes, and removals are all written to the organisation’s audit log, with who did it and when. Nothing in the product can edit or delete an entry once it is written.

Next: live and test environments.