Skip to content

Manage People and Access

Purpose

Invite people, inspect actual membership and assign scoped management roles.

Prerequisites

people.read reads people, people.manage invites and changes membership status, roles.read reads role definitions, and roles.manage manages bounded custom roles. Team membership uses team.members.manage. Protected ownership remains a separate authority.

Procedure

  1. Open Manage → People & access. In Invite a person, enter their actual address in Invite email, then select Send invitation below the field. Invitation status and expiry appear in the same panel.
  2. After acceptance, inspect their canonical Organization member record. Joining gives the Organization Member preset, not automatic Team, key or Chat access.
  3. Add Team membership with the intended Team role under Teams. Select the precise user and membership; inspect direct and directory source records.
  4. Use role administration to clone a preset or create a custom scoped role. Review sensitive captured-content access separately. Assign the role at the explicit Organization or Team scope. You can define and assign only roles whose permissions you hold yourself at that scope; see Grants stay within your own authority.
  5. Suspend/deactivate a person when required: in their person card, choose Status and select Update person status. The card shows the current status beside their name and email. Either status deletes their Console sessions, revokes their user keys, the keys' client connections and their management tokens, and deletes their own Connector connections and header values; reactivation restores none of these. Review their API caller grants as instance-bound authority; service-account keys remain attached to the service.
  6. Use account Access for your own scoped expiring management tokens. Store a revealed token once, and revoke it when no longer needed.

Expected result

Human roles control administration. They do not automatically give API inference. A departed person's old membership does not revive on rejoin; user key and API owner grants retain exact membership identity. Directory sync cannot override manual suspension.

Verification

Use a synthetic member to verify permitted Team screens and forbidden content/management screens. Remove the last source, verify existing key/session denial, then confirm a new membership does not revive the former key. Audit records retain the lifecycle change.

Failure recovery

If a role you expected is missing from the assignment list, or saving a custom role is refused, it contains a permission you do not hold at that scope: ask an Organization administrator to make the change. If a source is directory-managed, correct Identity/SCIM membership rather than editing adapter rows. Use the retained protected owner for identity recovery. Offline owner recovery refuses inactive or directory-disabled users and does not silently reactivate them. A new sign-in may be required after suspension or SSO changes.