Team and seats
Inviting people to RankX AI, what a seat counts, why Agency Clients do not consume one, and what happens to credentials when someone leaves.
A seat in RankX AI counts a member of your team: Agency Owners, Agency Admins and Members. Agency Clients do not consume a seat, because they are external users of one workspace rather than members of your organisation.
Seat limits are per plan, and they are in plans and limits.
Who counts
| Person | Consumes a seat |
|---|---|
| Agency Owner | Yes. Every agency always has at least one |
| Agency Admin | Yes |
| Member | Yes. Staff who do the work, without reaching the Agency Admin area |
| Agency Client | No |
The exemption is a shape decision rather than a generosity. The client portal exists so clients log in and read their own numbers, and pricing it per client user would make you ration a feature whose whole value is being used. See the client portal.
An agency always has an owner, enforced
The database refuses to remove or demote the last Agency Owner on an agency, so an agency can never end up with none. It is a trigger rather than a convention, and the error it raises says exactly that.
It does not forbid a second owner. What it guarantees is that billing and credential issuance always have somebody who can do them.
Two capabilities sit with the Owner role alone, and both for the same reason: they commit something nobody else can withdraw.
Billing, including plan changes.
MCP credentials. Issuing a personal access token or approving an OAuth connection creates a credential that can spend credits and edit a live public website, and its scopes are fixed at issue. See MCP authentication.
Transferring ownership is a deliberate act, not a side effect of an invitation.
Inviting someone
Staff are invited to the account and see what their role allows: every Client Workspace on the agency track, and everything on a Direct account.
Agency Clients are invited to one specific Client Workspace, and see only the sections that workspace permits.
Set a workspace's visibility permissions before inviting its first client user. An absent permission means allowed, so an unconfigured workspace shows the client everything in it, including any Website you parked there for convenience. See what clients can see.
Hitting the seat limit
Inviting another person is refused rather than queued. The remedy is to remove someone who has left or to change plan.
Being over a limit after a downgrade does not remove anyone: nothing is deprovisioned for you, and adding another is refused until you are back under.
When someone leaves
Removing a person revokes their access on their next request rather than at a later sweep.
It also revokes MCP credentials they created. A personal access token issued by someone who has left stops working, and an OAuth connection they approved stops with them.
That is the behaviour you want, and it is worth knowing before you remove the person who set up your integrations. Check the MCP settings page first: it lists every credential with its last use, so you can see what will stop.
If a credential is still needed after its creator leaves, issue a replacement from an account that will remain, update the client, and then remove the person. Rotation is zero downtime.
Before offboarding, in order
- List the MCP credentials and note which the person created.
- Reissue anything still needed from an account that will remain.
- Update the clients using them.
- Remove the person.
- Check nothing broke: the MCP settings page shows last-used times, so a connection that has stopped is visible rather than silent.
Where to go next
- Roles and permissions, for what each role can do.
- Security, for sessions and sign-out.
- MCP authentication, for credentials and revocation.