Members and invites
Console reference for the member roster: seat count, invitations, role changes, removal, and required permissions.
Path: Settings > Members
Rows show each member and their workspace-level roles. Project-scoped roles appear on the project's Access page.
Seat count
If you can invite, the strip under the title shows Seats in use, Seats left and your Plan. Members and pending invitations both count, so an invitation takes a seat from the moment you send it. Seat limits per plan: Billing and plans.
| State | Console behaviour |
|---|---|
| No seat limit on your plan | Seats left reads No limit. On Pro you add paid seats under Billing > Manage Seats; we never add them for you. On Enterprise, seats follow your agreement |
| Every seat in use | Seats left shows 0 in amber with an upgrade link; the invite button is disabled and says every seat is in use |
| Roster or invitations unreadable | The strip drops out; we disable the invite button and say usage could not be checked |
| You cannot invite | No strip and no Invitations tab: only an inviter reads pending invitations, so only their count is complete |
We re-check the seat cap on every invite and again when someone joins (by invitation, directory sync or single sign-on), in one step with the write, so a failed read or two requests at once never admit an extra seat.
Invite
| Field or rule | Value |
|---|---|
| Required | |
| Role | Only roles whose permissions you hold; we re-check on submit |
| Lifetime | 7 days |
| Resend | Mints a new link and retires the old one. One invitation can be resent every 10 minutes, up to 5 sends in all |
| Daily sending limits | We cap invitations per workspace, per inviter and per recipient address each day. Past one, we say which and ask you to try again tomorrow |
| The subject is always "You've been invited to a Penv Cloud workspace". Your workspace name, your address and the role appear only in the body, quoted | |
| Acceptance | /invite/accept; we require the invitee to be signed in with the invited address. If the workspace has no seat left by then, we refuse and the invitation stays pending |
Change a role
Role changes here apply workspace-wide; grant projects and environments on the Access page.
Remove a member
We mark the membership removed instead of deleting the row. On their next request, we end their sessions for your workspace and drop every grant they hold here, at any scope. Their account, shared with other workspaces, stays.
We refuse removal of the last owner. A workspace with no owner cannot be deleted or handed over.
Offboarding order: Offboard a member.
Required permissions
Full matrix: Roles and permissions. Step-up rules: Security and two-factor.
| Action | Permission | Step-up | Audit entry |
|---|---|---|---|
| Open the roster | member:read | No | none |
| Invite | member:invite | Two-factor and fresh | member.invited |
| Resend an invitation | member:invite | Yes | member.invite_resent |
| Withdraw an invitation | member:remove | No | member.invite_revoked |
| Change a member's role | member:role_assign | Two-factor and fresh | role.assigned |
| Remove a member | member:remove | Yes | member.deprovisioned and member.removed |
We record session revocation on removal in the sign-in history, not the audit log. Of these entries, only member.deprovisioned appears in the Audit Log action filter.
Next: Roles and permissions.