Compute
Invite people to your Compute account
Invite only recipients you are authorized to add, get approval for that exact set, give every member their own credentials, and read back every removal and revocation.
Before you start
You need administration authority over the account, the list of people you intend to add, and the grant each of them should hold.
Decide the grant before you write the invitation. An invitation sent first and scoped later is how someone ends up with authority nobody chose.
Select recipients you are authorized to add
Invite only addresses that belong to your organization, for people whose role you can name out loud.
Read your current directory rather than working from memory or an old spreadsheet. It tells you who exists now, under which address, and whether they are still active. See how to read your directory first.
Do not invite a shared mailbox or a team alias. An account member is one person, because a grant and a credential belong to one person.
Get approval for that exact set
Plan the invitations, then have them approved as a set. The approval covers exactly the recipients and grants in that plan.
If a name or a grant changes after approval, the plan changed. Build a new one rather than editing what was approved.
Invitations are not reversible by a configuration rollback. Withdrawing one is its own forward act, with its own record, so read the plan carefully before it is applied.
Give each member their own credentials
Every member gets their own identity and their own keys. Never pass an existing key to a new joiner to save a step.
Separate credentials give you three things a shared one destroys. A per-person budget, a per-person event trail, and the ability to revoke one person without stopping everyone else.
Grant the smallest set that lets them do their work. Widening later is one plan; recovering from an over-grant is an incident.
Confirm success
The invitation reads back as VERIFIED, the member appears with the grant you planned, and their first submission succeeds under their own credential.
Check one thing they should not be able to do, and confirm it refuses. An invitation that only proves access proves half of what you needed.
Read back every removal
Removal follows the same discipline as invitation, in reverse. Suspend or remove the member, then read the membership back, then check the events.
The remove response tells you the request was accepted. Only the read-back tells you the current state, and only the events tell you when it happened.
Then check for what removal does not cover. Service identities the person owned keep running, because they belong to the account rather than to them. Transfer each to a named owner or revoke it.
When something refuses
Read the reason and the next action together; every non-success carries both.
REFUSED on an invitation usually means the recipient or the grant is not permitted under your account policy. Change the input and plan again.
CONFLICT means the membership moved since your plan was built, often because someone else was editing it. Inspect the current state, plan again, and apply.