Members and Teams
Members are people in an organization. Teams group members for shared ownership, role assignment, budgets, attribution, and policy-aware workflows.
Prefer granting a role to a team when everyone in that team needs the same job function. A direct member role should have a named reason and review date.
Invite members
Open IAM → Members, then select Invite member. The invitation flow supports one recipient or a batch of up to 100 recipients.
Before sending:
- Confirm each email and organization.
- Choose the least-privilege organization role.
- Decide whether team-level assignment is more appropriate.
- Confirm the invitee can complete the configured SSO and MFA path.
- Send and monitor invitation state.
Owner roles are excluded from the ordinary invitation role choices. Promote an owner only through the deliberate owner-management workflow.
Pending invitations are not active membership. If an invitation remains pending, verify the address, expiry, domain/SSO policy, and whether it should be resent or revoked.
Use the member directory
The member list provides search and operational fields such as status, MFA, last activity, team count, session count, and token count where available.
Use those fields as investigation leads:
- no recent activity does not by itself authorize deletion;
- an MFA label describes enrollment state, not every login assurance detail;
- token count requires token-level review before offboarding; and
- team count does not show direct role grants.
Open the member detail page to review Permissions, Teams, Security, Tags, and Last accessed before changing access. A pending member also has an Invitation tab.
Create a team
Open IAM → Teams, then select Create team and give it:
- a stable functional name;
- a concise ownership description; and
- only the members needed for the shared scope.
On the team detail page, manage membership and role grants separately. A member's label inside a team and the IAM roles granted to the team solve different problems; do not rely on a display label as an authorization grant.
Change a member's access
When moving a member between functions:
- Add the new team or role.
- Test the resulting effective access with a representative non-owner account.
- Remove the old assignment.
- Inspect remaining direct and inherited access.
- Review Trail.
This overlap-first sequence avoids an unintended outage while still ending with least privilege. For urgent access removal, suspend first instead.
Suspend, reactivate, or remove
| Action | Use when | Reversible |
|---|---|---|
| Suspend | Access must stop now but investigation or return is possible | Yes, through reactivation |
| Reactivate | The member is approved to regain access | Yes |
| Remove from team | Only one team's scope should end | Yes, by adding again |
| Remove organization membership | The person must leave the organization | Treat as destructive |
Before organization removal:
- preserve required audit and work records;
- inventory owned tokens, OAuth relationships, sessions, teams, budgets, tags, and assignments;
- transfer operational ownership;
- suspend first when immediate containment is required;
- obtain the required approval; and
- verify the result in Trail.
Removal from one team does not revoke direct roles or roles inherited from other teams.
Bulk actions
The member inventory can bulk suspend, change roles, or remove eligible members. Use bulk operations only when every selected member has the same approved outcome.
Before confirming:
- Export or record the selected IDs.
- Check that owners and service-critical accounts are not included.
- Review the new role for each selected member.
- Use a small first batch.
- Verify the result and Trail events.
CLI workflow
kt user list
kt team list
kt team list-members --team-id team_example
kt role show-assignments --role-id role_example
See IAM, Members, Teams, and Roles for mutation commands.