> For the complete documentation index, see [llms.txt](https://umber.gitbook.io/umber/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://umber.gitbook.io/umber/guides/managing-team-members.md). # Managing Team Members Everything after the invitation: finding people, changing what they can do, suspending access, removing them, and handling passwords. The **Users** area is visible to owners, admins, developers and creators; only owners and admins can change anything. Viewers cannot see it at all. See [Roles and Permissions](/umber/concepts/roles-and-permissions.md). ## The members list **Users** groups everyone into three sections: * **Active** — people who have accepted and can sign in. Expanded by default. * **Invitations** — sent but not yet accepted, including expired and revoked ones. * **Deactivated** — switched off, but still yours. Every card states its status in words rather than relying on colour alone: *Active*, *Invite pending*, *Invite expired*, *Invite revoked*, or *Deactivated*. Your own card is marked so you can tell at a glance which one you're looking at. Your seat usage sits beside the **Users** title and turns red when the plan is full. ## Editing someone's details Open a member and choose **Edit Details**. You can change their **name** and **phone number**; clearing the phone number entirely is allowed. The same all-or-nothing rule applies as on the invite form: a country code without a number, or a number without a code, is rejected. {% hint style="info" %} **Role is not on this form**, deliberately. Changing a role signs the person out everywhere, which is too significant to sit alongside a name correction. It has its own control on the detail page. {% endhint %} A pending invitee cannot be edited by anyone — there's nothing to edit until they've joined. ## Changing a role Owners and admins can change another member's role from their detail page. Only roles you're permitted to grant are offered, so an admin never sees Owner in the list. The role takes effect immediately, and **the person is signed out of every device**. That is what makes a demotion real at once rather than whenever their session happened to lapse. Re-selecting the role they already have does nothing and signs nobody out. Three refusals to expect: * You cannot change **your own** role. * An admin cannot change an **owner's** role. * The **last remaining owner** cannot be demoted. Promote someone else first. ## Deactivating and reactivating The **Active** toggle on a member's card and detail page switches access off without losing anything. You'll be asked to confirm, and told what it does. **Deactivating:** * ends their sessions immediately — they're signed out everywhere and can't sign back in * **returns their seat**, so you can invite someone else straight away * keeps their record, role and history intact * is allowed even when your plan is already full, so you can always get back under your limit **Reactivating** restores them exactly as they were — but it **takes a seat back**, so it's refused if your plan is full. Free a seat first. The toggle isn't offered for your own account or for a pending invitee. {% hint style="warning" %} **Deactivating does not free their email address.** The account still belongs to your workspace, which is what makes reactivation possible — but it means they can't be invited into a different Umber workspace until you remove them properly. See [Workspaces and Members](/umber/concepts/workspaces-and-members.md). {% endhint %} Two guards apply: an admin cannot deactivate an owner, and you cannot deactivate the last remaining owner or admin. Umber does **not** email someone to say they've been deactivated. That decision is yours to communicate, and an automated notice can reach a person before their employer does. ## Removing someone Deletion is offered only for members who are eligible for it — an active user cannot be deleted. **Deactivate first, then delete.** You'll be asked to type the person's exact email address to confirm. This is intentional friction: unlike deactivation, removal cannot be undone. Removing frees their email address, so they can be invited by another workspace or sign up for one of their own. | | Seat returned | Address freed | Reversible | | -------------- | ------------- | ------------- | ---------------------- | | **Deactivate** | Yes | No | Yes | | **Remove** | Yes | Yes | No — invite them again | ## Passwords and sign-in Each member's detail page has a **Security** tab. Any member can open it on **their own** profile, whatever their role. The **Sign-in Method** row reports how that person actually signs in — a password, Google, or both. If that information can't be retrieved the row says so and the rest of the page still works. ### On your own profile You'll see a single **Update Password** action. Changing your own password signs out your **other** sessions but leaves the one you're using — you stay signed in on the device you're on. ### On someone else's profile Owners and admins see two actions in the Password row: * **Set a new password** directly. * **Send Reset Link** — emails the member a link so they can choose their own. Requests are rate-limited per address, so repeated attempts in quick succession are throttled. Changing another person's password signs that person out **everywhere**. {% hint style="info" %} Password actions are disabled for an account that has no password — someone who only ever signs in with Google. Send them a reset link instead if they need one. {% endhint %} ## Related * [Inviting Team Members](/umber/guides/inviting-team-members.md) * [Roles and Permissions](/umber/concepts/roles-and-permissions.md) * [Workspaces and Members](/umber/concepts/workspaces-and-members.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://umber.gitbook.io/umber/guides/managing-team-members.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.