Manage members

Add people to a tenant, inspect their access, and remove ordinary membership without deleting accounts or content.

Agentic Friendly

Use Administration → Access Control → Members to manage people in the selected tenant. This Portal guide is for administrators of the selected tenant. Delegated membership permissions can authorize API operations without granting entry to Administration.

Before you begin

You must administer the selected tenant to use these Portal controls. Choose the intended organization in Tenant to manage. Opening Members requires tenant.member.list. Identity details and removal controls also require tenant.group.list; role inspection requires tenant.role.list.

ActionAdditional permission
Add an existing accounttenant.member.add
Create a local accounttenant.member.create_local
Remove ordinary membershiptenant.member.remove
Assign or revoke a functional roletenant.role.assign or tenant.role.revoke

Directory access is not permission to change every identity. Protected administrators and federation-managed memberships cannot be removed from this page.

Find and inspect a member

Search the Members list by user name, group, or role, then open a member's details. Inspect their groups, Assigned roles, and Inherited roles.

Assigned roles are direct grants. Inherited roles come through groups and cannot be edited as direct assignments. Follow a group or role relationship to inspect the source of access when the corresponding directory is available to you.

Add an existing account

  1. Select Add member, then Existing account.
  2. Enter the exact email address of the account already known to the platform.
  3. Select Add member and wait for the result.
  4. Find the person in the refreshed list and verify access to the intended tenant.

This adds tenant membership; it is not an invitation email or a new account in the corporate identity provider. If the account cannot be found, resolve the identity with its administrator rather than creating a duplicate.

Create a local account

Use this when a local platform account is appropriate and the deployment permits it. It does not create a corporate-directory account or bypass existing sign-in restrictions.

  1. Select Add member → Create local account.
  2. Enter the email address, first name, last name, and a temporary password.
  3. Use a password of 12–256 characters that also satisfies the platform's password policy.
  4. Select Create local account and wait for confirmation.
  5. Share the temporary password securely with the user. No email is sent; the user must change the password at first sign-in.
  6. Verify that the user can sign in to the intended tenant, then grant any additional functional roles separately.

An existing email or username cannot be converted into a local account through this flow. Enabled external user-storage providers can also prevent local account creation; ask the identity administrator to resolve the configuration rather than weakening federation policy.

Change direct roles

Open the member's details and use Assigned roles to search for and select eligible system or custom roles. Additions and removals save as you change the selection; wait for the result before making another change.

Removing a direct role does not remove the same access inherited from a group or another role. Use Manage roles and permissions to inspect the permission bundle and assignment behavior. Tenant-administrator authority is managed separately from functional roles.

Remove a member

  1. Open the member's details and inspect their access.
  2. Select Remove member when available and confirm the removal.
  3. Refresh the directory and verify that the tenant membership and effective functional access have been removed.

Removal retains the user's account and content. It is not account deletion. If the control is unavailable for an administrator or federation-managed identity, use the corresponding administrator-assignment or identity-provider process.

Verify changes

Membership and role changes synchronize asynchronously. A request acknowledgement is not proof that effective access has already changed. Refresh the directory and verify the intended action with the affected user after synchronization.

If a request is not fully confirmed, refresh before retrying: membership may already have changed. Check both a newly allowed action and access that should remain denied.

On this page