# Managing members

> Inviting people, assigning roles, resetting passwords, and removing access.

Source: https://triagic.com/docs/admin/members

**Organization → Members** lists everyone in the organization with their role and
team memberships.

## Adding a member [#adding-a-member]

**New member** asks for three things:

| Field        | Notes                                                                        |
| ------------ | ---------------------------------------------------------------------------- |
| **Username** | What they sign in with and how they appear in the app. Fixed after creation. |
| **Email**    | Also usable to sign in, and where the invite is sent. Fixed after creation.  |
| **Role**     | `member` or `org admin`. See [Roles](/docs/concepts/roles-and-access#roles). |

There is no password field. Creating the member emails them an invite with a link to
choose their own password, so an initial credential never has to travel over chat.
Point them at [Install the desktop app](/docs/desktop/install) once they have set it.

### The invite email [#the-invite-email]

The link goes to a **set-password** page in the portal. It is **single-use** (using
it spends the link) and it **expires after 7 days**. Only the link's hash is stored,
so nobody, us included, can read the link back out of the database.

Until the link is used, the account cannot be signed into at all: the row is created
with an unusable random password, not a blank or guessable one.

Invites, like the signup verification email, render through the same branded
transactional template, and go out from a `noreply@` sender with replies directed to
[hello@triagic.com](mailto:hello@triagic.com).

> **Warning:** If the invite email fails to send
>
> The member row still exists (delivery is best-effort and is not allowed to fail the
> creation) but nobody can sign into it. The dialog says so instead of closing, and
> names the error. Retry with **Resend invite** from the member's row, or set a
> password for them by hand from **Edit** and send it to them.

A link that expired or was lost is recovered with the **Resend invite** action (the
envelope icon) on the member's row, which mints a fresh link and emails it. Reissuing
replaces the old link rather than adding a second live one, and leaves any password
the member already set untouched until the new link is used. The expiry message
(*"This link has expired. Ask your administrator to re-invite you."*) is pointing at
this. Resending is blocked for disabled members — re-enable them first.

> **Note:** Username and email are fixed
>
> Editing an existing member covers role and password only. If someone's address
> changes, create a new member and disable the old one. The audit trail stays coherent
> that way.

### If you hit the seat limit [#if-you-hit-the-seat-limit]

> You're at your seat limit (*n*). Add seats to invite more.

Buy more seats on the **Account** page, or disable someone who no longer needs
access. A disabled member doesn't consume a seat. See
[Roles, plans and seats](/docs/concepts/roles-and-access#how-the-seat-cap-bites).

## Editing a member [#editing-a-member]

The edit dialog covers:

* **Role**: promote to org admin or demote to member.
* **New password**: leave blank to keep the current one. This is how you reset a
  password for someone who is locked out.

Team membership is *not* edited here. It lives on the team, in the **Teams** tab.
See [Teams](/docs/admin/teams).

## Assigning add-on seats [#assigning-add-on-seats]

Purchased add-on seats appear as a column per add-on in the members table, with a counter such as "2 of 5 Forms + email seats assigned". Tick the box for a member to give them the add-on; untick to free the seat. The change reaches that member's desktop within one sync cycle (about 15 minutes) or on their next sign-in.

If every purchased seat is assigned, the box is disabled. Buy more from **Account**.

## Removing someone [#removing-someone]

The delete button **disables** the account rather than deleting it. They lose access
immediately: the next authenticated call from their desktop fails, so this is not
something they can outrun by staying signed in.

The row stays, marked **disabled**, with an **Enable** button to reverse it. This is
deliberate: synced desktop installs keep their history and its attribution intact, so
"who ran this investigation" still has an answer after someone leaves.

## The owner's row [#the-owners-row]

The account owner appears in the list with an **owner** badge and no edit or disable
controls, just a pointer to **Account settings**.

Their email, password and role are all managed on the **Account** page rather than
here, so that one human keeps one password and still shows up in every directory
view. They also cannot be added to a team. See [Teams](/docs/admin/teams).

## Guardrails [#guardrails]

* You cannot change **your own** role.
* You cannot disable **yourself**.

Both are enforced server-side, not just hidden in the UI, so an organization cannot
end up with nobody able to administer it.

## What members see of all this [#what-members-see-of-all-this]

A member can open the Organization page and see the roster and the teams. They cannot
create, edit or disable anyone, and the spend cap and default-connector cards are not
rendered for them at all.